openstack team mailing list archive

[Vladimir Popovski <vladimir@xxxxxxxxxxxxxxxxx>]

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