Hi Vish & All, We would definitely prefer to leave the code in place and ready to fix any issues related to it.
We found out that it is extremely hard to work with latest trunk version - our QA was constantly complaining about different regression scenarios and we decided to stick with released stable Nova branches and perform merges either after main releases or major milestones. The current VSA code in trunk is completely functional & working. We've done tons of enhancements to it and added new functionality during last 4-5 month. As I mentioned before our plan was to merge it with latest relatively stable Essex code and to have this code in somewhere at the beginning of Folsom. At the same time we understand your concerns - without proper documentation and related packages (like VSA image & drive discovery packages) it is very hard to use/test it. We are ready to collaborate with whoever is interested in order to make this functionality generic enough. From our side we will try to fix it. Please let us know what should we do in order to leave it in place. Thanks, -Vladimir Zadara Storage -----Original Message----- From: openstack-bounces+vladimir=zadarastorage....@lists.launchpad.net [mailto:openstack-bounces+vladimir=zadarastorage....@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, March 14, 2012 6:54 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] Removal of VSA Code Apologies if you receive this email twice, I sent the first one from the wrong address. Hello Everyone, Last week during the release meeting it was mentioned that the VSA code is not working properly and we should either fix it or remove it. I propose to remove it for the following reasons: * Lack of documentation -- unclear how to create a vsa image or how the image should function * Lack of support from vendors -- originally, the hope was other vendors would use the vsa code to create their own virtual storage arrays * Lack of functional testing -- this is the main reason the code has bitrotted * Lack of updates from original coders -- Zadara has mentioned a few times that they were going to update the code but it has not happened * Eases Transition to separate volume project -- This lowers the surface area of the volume code and makes it easier to cleanly separate the volume service to compute As far as I can tell Zadara is maintaining a fork of the code for their platform, so keeping the code in the public tree doesn't seem necessary. I would be happy to see this code come back in Folsom if we get a stronger commitment to keep it up-to-date, documented, and maintained, and there is a reasonable location for it if the volume and compute code is separate. If anyone disagrees, please respond ASAP. Vish _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
