[vdsm] blame and shame
Hi list! Since I'm doing lately and I plan to continue to do patches to improve pep8 compliance for the whole vdsm codebase, and a lot of that is E126, E127 and E128, that deal with whitespaces, I have added to my ~/.gitconfig [alias] bl = blame -w Which ignores whitespaces for the blame on the lines. This way, my name will not be shown next to code I don't know about ;-) Of course, it would be great if git blame where to be extended with pydiff so all the pep8 changes would be ignored for blaming purposes... But I'll leave that to someone else ;-) Best, Toni ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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] blame and shame
I kind of like the fact that I will not be blamed for all the stuff I broke. :( - Original Message - > From: "Antoni Segura Puimedon" > To: vdsm-devel@lists.fedorahosted.org > Sent: Thursday, December 13, 2012 10:34:52 AM > Subject: [vdsm] blame and shame > > Hi list! > > Since I'm doing lately and I plan to continue to do patches to > improve > pep8 compliance for the whole vdsm codebase, and a lot of that is > E126, E127 and E128, that deal with whitespaces, I have added to my > ~/.gitconfig > > [alias] > bl = blame -w > > Which ignores whitespaces for the blame on the lines. This way, my > name > will not be shown next to code I don't know about ;-) Of course, it > would > be great if git blame where to be extended with pydiff so all the > pep8 > changes would be ignored for blaming purposes... But I'll leave that > to > someone else ;-) > > Best, > > Toni > ___ > 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] Request for consideration during the API revamp
Since I assume vdsClient will use libvdsm. It should have all the constants defined. I do like Adam's suggestion about making vdsClient auto-generated as well. vdsClient is currently very annoying to maintain. I would also like to propose changing the name of the executable to vdsm_cli. It would make it easier to distribute both tools as vdsClient will still be needed communicate with old VDSMs. Also capital letters in executable names is not very Unixy. - Original Message - > From: "Adam Litke" > To: "Vinzenz Feenstra" > Cc: vdsm-devel@lists.fedorahosted.org > Sent: Wednesday, December 12, 2012 10:40:19 AM > Subject: Re: [vdsm] Request for consideration during the API revamp > > On Wed, Dec 12, 2012 at 02:01:31PM +0100, Vinzenz Feenstra wrote: > > Hi, > > > > When there is the attempt to enhance/change the current API, I > > would > > ask you to consider to think also about the vdsClient use case. > > I haven't read anything regarding that so far and therefore I just > > want you to think about it as well. > > > > My expectation is that the vdsClient will continue to use the RPC > > interfaces, however since it is part of the VDSM project I think it > > would be a good idea if there is a way for both vdsmd and vdsClient > > to share constants used for the API. > > > > That in turn also should simplify the maintenance of vdsClient. > > Currently I see the constants used by both being defined on both > > sides and I am pretty sure that this could be improved. > > > > See this as just a thought on the whole redesign talk, but I would > > like to see this kind of use cases to be covered. :-) > > Yes, this is an excellent suggestion. One thing I am thinking about > doing is > generating a new python file with the enums defined in the schema. > This could > be included by all server-side code and by clients such as vdsClient. > If we > decide to add constants to the schema file, we could also place these > into the > same generated python file. > > -- > Adam Litke > IBM Linux Technology Center > > ___ > 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
