openstack team mailing list archive

[Vladimir Popovski <vladimir@xxxxxxxxxxxxxxxxx>]

Hi Vish,

I was not aware of any issue with VSA code in diablo/stable (or at least
major issues).
Of course, we've done tons of changes to it lately and probably there were
some bugs that were fixed later, but I'm sure this particular code is
fully functional.

We will need to look closer on planned separation of volume & compute code
and understand what will be the best place for our VSA code. Probably we
can discuss it during summit.

>From my previous experience with merges - it will be way easier (at least
for us) to provide an upgrade for the code rather than to push a
completely new code.

Thanks,
-Vladimir


-----Original Message-----
From: Vishvananda Ishaya [mailto:vishvananda@xxxxxxxxx]
Sent: Thursday, March 15, 2012 8:57 AM
To: Vladimir Popovski
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Removal of VSA Code

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@lists.launchpad.n
> et]
> 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