[vdsm] refactor clientif move the api implement to sub-module
Hi, folks I am trying move api implement to sub-module, then we don't need singleton and passing clientif to anywhere. So I sent this mail to descript the idea. I think it's good for review. So I add api registeration mechanism. Other modules can register it's api implement to api layer. I try to move VM api and vm stuff(like clientif.vmContainer, etc) to a new module called vmm. the vmm.VMM is similar with hsm. It's responsiable for managing vm and register VM implement to api layer. Same with hsm, I move all storage related api to hsm, and hsm will register them to api layer. After all api move to submodule, we can rename clientif and needn't passing client to any where. :) I have already submit a rough version to gerrit: http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:wip_refactor_clientif,n,z Appreciate any comment and review! Thanks! He Jie ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] refactor clientif move the api implement to sub-module
On Wed, Jun 20, 2012 at 06:08:57PM +0800, Xu He Jie wrote: Hi, folks I am trying move api implement to sub-module, then we don't need singleton and passing clientif to anywhere. So I sent this mail to descript the idea. I think it's good for review. So I add api registeration mechanism. Other modules can register it's api implement to api layer. I try to move VM api and vm stuff(like clientif.vmContainer, etc) to a new module called vmm. the vmm.VMM is similar with hsm. It's responsiable for managing vm and register VM implement to api layer. Same with hsm, I move all storage related api to hsm, and hsm will register them to api layer. After all api move to submodule, we can rename clientif and needn't passing client to any where. :) I have already submit a rough version to gerrit: http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:wip_refactor_clientif,n,z I took a cursory look at the code you have submitted. I think you need to more thoroughly describe your design. I was particularly confused by your use of Abstract Base Classes for this scenario. Can you explain in more depth why you have done this? Is there a simpler way to accomplish what you need to do? I looked at your VMM patch and I am unsure why you need to define VMBase and VMImpl separately. It means declaring the set of functions in two separate files. Thanks for shining some more light on your methodology. -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] refactor clientif move the api implement to sub-module
于 2012年06月21日 03:10, Adam Litke 写道: On Wed, Jun 20, 2012 at 06:08:57PM +0800, Xu He Jie wrote: Hi, folks I am trying move api implement to sub-module, then we don't need singleton and passing clientif to anywhere. So I sent this mail to descript the idea. I think it's good for review. So I add api registeration mechanism. Other modules can register it's api implement to api layer. I try to move VM api and vm stuff(like clientif.vmContainer, etc) to a new module called vmm. the vmm.VMM is similar with hsm. It's responsiable for managing vm and register VM implement to api layer. Same with hsm, I move all storage related api to hsm, and hsm will register them to api layer. After all api move to submodule, we can rename clientif and needn't passing client to any where. :) I have already submit a rough version to gerrit: http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:wip_refactor_clientif,n,z I took a cursory look at the code you have submitted. I think you need to more thoroughly describe your design. I was particularly confused by your use of Abstract Base Classes for this scenario. Can you explain in more depth why you have done this? Is there a simpler way to accomplish what you need to do? I looked at your VMM patch and I am unsure why you need to define VMBase and VMImpl separately. It means declaring the set of functions in two separate files. Thanks for shining some more light on your methodology. Adam, Thanks for reply! I want to force people declare their API interface before they implement it. the vdsm API should be standard, stable, it won't be modified frequently. And anyone should implement the API as the definition. So I added Abstract Base Classes. The API interface must be declared at API.py, then people must implement as the API.py defined. I think it more clear for people want to implement the vdsm API. People can find the API definition from API.py and implement it as the interface definition. As example, VMBase is the vdsm VM API interface definition in API.py. VMBase is an Abstract Base Class. so VMImpl is an implement of VM API. When I register VMImpl to API layer by the function 'API.registAPI()'. 'API.registAPI()' will check VMImpl to ensure VMImpl implement VM API as definition of VMBase in API.py. If we didn't define API interface, so people will confuse what is vdsm API looks like and which implement of API is standard. Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] refactor clientif move the api implement to sub-module
于 2012年06月21日 11:03, Shu Ming 写道: On 2012-6-21 10:35, Xu He Jie wrote: 于 2012年06月21日 03:10, Adam Litke 写道: On Wed, Jun 20, 2012 at 06:08:57PM +0800, Xu He Jie wrote: Hi, folks I am trying move api implement to sub-module, then we don't need singleton and passing clientif to anywhere. So I sent this mail to descript the idea. I think it's good for review. So I add api registeration mechanism. Other modules can register it's api implement to api layer. I try to move VM api and vm stuff(like clientif.vmContainer, etc) to a new module called vmm. the vmm.VMM is similar with hsm. It's responsiable for managing vm and register VM implement to api layer. Same with hsm, I move all storage related api to hsm, and hsm will register them to api layer. After all api move to submodule, we can rename clientif and needn't passing client to any where. :) I have already submit a rough version to gerrit: http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:wip_refactor_clientif,n,z I took a cursory look at the code you have submitted. I think you need to more thoroughly describe your design. I was particularly confused by your use of Abstract Base Classes for this scenario. Can you explain in more depth why you have done this? Is there a simpler way to accomplish what you need to do? I looked at your VMM patch and I am unsure why you need to define VMBase and VMImpl separately. It means declaring the set of functions in two separate files. Thanks for shining some more light on your methodology. Adam, Thanks for reply! I want to force people declare their API interface before they implement it. the vdsm API should be standard, stable, it won't be modified frequently. And anyone should implement the API as the definition. So I added Abstract Base Classes. The API interface must be declared at API.py, then people must implement as the API.py defined. I think it more clear for people want to implement the vdsm API. People can find the API definition from API.py and implement it as the interface definition. As example, VMBase is the vdsm VM API interface definition in API.py. VMBase is an Abstract Base Class. so VMImpl is an implement of VM API. When I register VMImpl to API layer by the function 'API.registAPI()'. 'API.registAPI()' will check VMImpl to ensure VMImpl implement VM API as definition of VMBase in API.py. If we didn't define API interface, so people will confuse what is vdsm API looks like and which implement of API is standard. Who will give the definition of the API interfaces? In my mind, the one giving the definitions may be different form the implementors. What is the format of the definitions will be like? VDSM will give the definition of the API interfaces. Other implementor just implement the interface. VMBase is one of API interface definition. Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
