[Engine-devel] [virt-node] VDSM as a general purpose virt host manager
There is an important discussion starting about the future of the VDSM API on vdsm-devel. If you want to be involved in the future of the VDSM API don't miss out and join vdsm-devel. To sign up go to https://fedorahosted.org/mailman/listinfo/vdsm-devel There growing need for a way to more easily reuse of the functionality of VDSM in order to service projects other than Ovirt-Engine. Originally VDSM was created as a proprietary agent for the sole purpose of serving the then proprietary version of what is known as ovirt-engine. Red Hat, after acquiring the technology, pressed on with it's commitment to open source ideals and released the code. But just releasing code into the wild doesn't build a community or makes a project successful. Further more when building open source software you should aspire to build reusable components instead of monolithic stacks. We would like to expose a stable, documented, well supported API. This gives us a chance to rethink the VDSM API from the ground up. There is already work in progress of making the internal logic of VDSM separate enough from the API layer so we could continue feature development and bug fixing while designing the API of the future. In order to achieve this though we need to do several things: 1. Declare API supportability guidelines 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) 3. Make the API easily consumable (e.g. proper docs, example code, extending the API, etc) 4. Implement the API itself All of these are dependent on one another and the permutations are endless. This is why I think we should try and work on each one separately. All discussions will be done openly on the mailing list and until the final version comes out nothing is set in stone. If you think you have anything to contribute to this process, please do so either by commenting on the discussions or by sending code/docs/whatever patches. Once the API solidifies it will be quite difficult to change fundamental things, so speak now or forever hold your peace. Note that this is just an introductory email. There will be a quick follow up email to kick start the discussions. Don't forget to sign up to the vdsm-devel mailing list.
There is an important discussion starting about the future of the VDSM API on vdsm-devel. If you want to be involved in the future of the VDSM API don't miss out and join vdsm-devel. To sign up go to https://fedorahosted.org/mailman/listinfo/vdsm-devel
There growing need for a way to more easily reuse of the functionality of VDSM in order to service projects other than Ovirt-Engine.
Originally VDSM was created as a proprietary agent for the sole purpose of serving the then proprietary version of what is known as ovirt-engine. Red Hat, after acquiring the technology, pressed on with it's commitment to open source ideals and released the code. But just releasing code into the wild doesn't build a community or makes a project successful. Further more when building open source software you should aspire to build reusable components instead of monolithic stacks.
We would like to expose a stable, documented, well supported API. This gives us a chance to rethink the VDSM API from the ground up. There is already work in progress of making the internal logic of VDSM separate enough from the API layer so we could continue feature development and bug fixing while designing the API of the future.
In order to achieve this though we need to do several things: 1. Declare API supportability guidelines 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) 3. Make the API easily consumable (e.g. proper docs, example code, extending the API, etc) 4. Implement the API itself Now, VDSM version was highly bound with oVirt Engine version. In order to make oVirt to work, both VDSM and ovirt engine should be synced with
On 2012-6-20 5:32, Saggi Mizrahi wrote: the latest binary, no back compatibility yet. If we want to break this binding out, we should classify the level of the VDSM APIs like these: 1) public stable 2) public evolving 3) undocumented volatile And the we should make sure public stable interfaces to be supported in a very long time as possible as we can. public evolving interfaces should keep the compatibility in the same major release(ie, 4.x.x). undocumented volatile is not recommended to the application and it is the responsibility of the application to take the risk.
All of these are dependent on one another and the permutations are endless. This is why I think we should try and work on each one separately. All discussions will be done openly on the mailing list and until the final version comes out nothing is set in stone.
If you think you have anything to contribute to this process, please do so either by commenting on the discussions or by sending code/docs/whatever patches. Once the API solidifies it will be quite difficult to change fundamental things, so speak now or forever hold your peace. Note that this is just an introductory email. There will be a quick follow up email to kick start the discussions. Don't forget to sign up to the vdsm-devel mailing list. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Shu Ming <shuming@linux.vnet.ibm.com> IBM China Systems and Technology Laboratory
participants (2)
-
Saggi Mizrahi -
Shu Ming