openstack team mailing list archive

[Brian Waldon <brian.waldon@xxxxxxxxxxxxx>]

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.com@xxxxxxxxxxxxxxxxxxx
>> [mailto:openstack-bounces+vladimir=zadarastorage.com@xxxxxxxxxxxxxxxxxxx]
>> On Behalf Of Vishvananda Ishaya
>> Sent: Wednesday, March 14, 2012 6:54 PM
>> To: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp