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.
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.
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.
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?
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.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Adam Litke" agl@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
On Tue, Dec 11, 2012 at 05:44:50AM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Adam Litke" agl@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.
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.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Andrew Cathrow" acathrow@redhat.com, "Yaniv Bronheim" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Adam Litke" agl@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" danken@redhat.com To: "Adam Litke" agl@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.
On Tue, Dec 11, 2012 at 01:56:40PM -0500, Andrew Cathrow wrote:
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Andrew Cathrow" acathrow@redhat.com, "Yaniv Bronheim" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Adam Litke" agl@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" danken@redhat.com To: "Adam Litke" agl@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.
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.
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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
----- 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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com 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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com 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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Friday, December 14, 2012 2:07:04 AM Subject: Re: [vdsm] Host bios information
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com 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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
On 12/16/2012 06:24 PM, Barak Azulay wrote:
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Friday, December 14, 2012 2:07:04 AM Subject: Re: [vdsm] Host bios information
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com 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:
- Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g LENOVO)
- Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s)
- Host Product Name - ID of the product - same for all similar products (e.g 4174BH4)
- Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897)
- Host Family - Type of host's CPU - (e.g Core i5)
- 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
Agree, In vdsm side as Andrew suggested we can add new xml-rpc Api that internally calls by getCapabilities until we will define the flow changes that we need to do in the engine side to permit split calls that fill VDS object fields.
Before we change the engine side to perform 2 calls to fill vds data, we need to define the flows for retrieving the data, in which table to keep it, and when to refresh it. getCapabilities API call signs for the engine that the host is operational. By performing another API call we will get into cases that we've never checked and we need to define and test.
This feature can be split to 2 levels, first we have the requirement for 6 field, and only those fields (as i mentioned in the wiki), those can be added as part of host capabilities structure, in declared structure that defines the bios information, until we define the new api. Additionally, we can add vdsm API the returns only this structure for future use by the engine.
Anyhow, when defining new structure for bios information we can add more values of dmidecode in the future if the users will request for such info, and it won't effect the changes we add to the UI as part of this feature.
IMPOV, I think we should implement that feature as described now in the engine side. Using new vdsm API by the engine should be part of another feature that arranges getCapabilities variables, defines the flows of requesting bios variables and in which VDS table engine should store this data.
The engine part patches of this feature are: http://gerrit.ovirt.org/#/c/10114/ - Modifying db tables http://gerrit.ovirt.org/#/c/9337/ - Adding bios data to backend's objects http://gerrit.ovirt.org/#/c/10115/ - UI changes to add host subtab for Bios info
vdsm part: http://gerrit.ovirt.org/#/c/9258/ - will be modified asap to external structure.
I would appreciate your comments and reviews
thanks!
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" shuming@linux.vnet.ibm.com To: "ybronhei" ybronhei@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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: shuming@cn.ibm.com or shuming@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
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "ybronhei" ybronhei@redhat.com To: "Barak Azulay" bazulay@redhat.com Cc: "engine-devel" engine-devel@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Sunday, December 16, 2012 12:04:32 PM Subject: Re: [vdsm] [Engine-devel] Host bios information
On 12/16/2012 06:24 PM, Barak Azulay wrote:
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Friday, December 14, 2012 2:07:04 AM Subject: Re: [vdsm] Host bios information
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Shu Ming" shuming@linux.vnet.ibm.com 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:
- 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
Agree, In vdsm side as Andrew suggested we can add new xml-rpc Api that internally calls by getCapabilities until we will define the flow changes that we need to do in the engine side to permit split calls that fill VDS object fields.
Before we change the engine side to perform 2 calls to fill vds data, we need to define the flows for retrieving the data, in which table to keep it, and when to refresh it. getCapabilities API call signs for the engine that the host is operational. By performing another API call we will get into cases that we've never checked and we need to define and test.
This feature can be split to 2 levels, first we have the requirement for 6 field, and only those fields (as i mentioned in the wiki), those can be added as part of host capabilities structure, in declared structure that defines the bios information, until we define the new api. Additionally, we can add vdsm API the returns only this structure for future use by the engine.
Anyhow, when defining new structure for bios information we can add more values of dmidecode in the future if the users will request for such info, and it won't effect the changes we add to the UI as part of this feature.
IMPOV, I think we should implement that feature as described now in the engine side. Using new vdsm API by the engine should be part of another feature that arranges getCapabilities variables, defines the flows of requesting bios variables and in which VDS table engine should store this data.
The engine part patches of this feature are: http://gerrit.ovirt.org/#/c/10114/ - Modifying db tables http://gerrit.ovirt.org/#/c/9337/ - Adding bios data to backend's objects http://gerrit.ovirt.org/#/c/10115/ - UI changes to add host subtab for Bios info
I think we are still missing some information even for the smaller subset - eg asset tag
James can you do a little research with our oem partners and see which makes sense
vdsm part: http://gerrit.ovirt.org/#/c/9258/ - will be modified asap to external structure.
I would appreciate your comments and reviews
thanks!
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" shuming@linux.vnet.ibm.com > To: "ybronhei" ybronhei@redhat.com > Cc: "VDSM Project Development" > vdsm-devel@lists.fedorahosted.org > 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: > shuming@cn.ibm.com > or > shuming@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
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- 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
vdsm-devel@lists.fedorahosted.org