I would like to add that the complete lack of documentation makes the VSA code unusable. I have no idea where to get started with it. The following bug has been open and assigned for the past 6+ months: https://bugs.launchpad.net/nova/+bug/835099. The fact that you are maintaining a fork of Nova with your own enhancements also reinforces the idea that VSA should not live within the Nova codebase. We are also in our release-candidate phase, so any major code 'enhancements' should *not* be landing.
Brian On Mar 15, 2012, at 8:56 AM, Vishvananda Ishaya wrote: > Vladimir, > > Are you sure the code in trunk is working? Investigation by one of the > community members showed that it was broken. If you are planning on merging > your new code in, perhaps it is better to do it all at once? FYI, > nova-volume is going to be split into its own service during folsom, and > based on the fact that vsa uses both compute and volume, it might be best to > actually move it into its own project as well. > > This will keep separation of concerns and allow you to maintain it more > directly in the public. I still think the best approach for now is to pull it > and bring back the fully functional version in Folsom. No one is using it in > its current state. > > Vish > > On Mar 15, 2012, at 8:48 AM, Vladimir Popovski wrote: > >> 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
