fix/remove nova VSA support

[Joe Gordon]

Nova VSA is broken. For Essex there are four options:

a) disable the extension but leave code in place
b) remove the exension completely but leave other code
c) remove all code but db
d) remove all code and db and migrate the tables out.

relavent files:

bin/nova-vsa
nova/db/sqlalchemy/migrate_repo/versions/043_add_vsa_data.py
nova/scheduler/vsa.py
nova/tests/api/openstack/compute/contrib/test_vsa.py
nova/tests/scheduler/test_vsa_scheduler.py
nova/tests/test_vsa.py
nova/tests/test_vsa_volumes.py
nova/vsa/__init__.py
nova/vsa/api.py
nova/vsa/connection.py
nova/vsa/fake.py
nova/vsa/manager.py
nova/vsa/utils.py

[Brian Waldon (bcwaldon)]

I'd vote for removing the extension at a minimum.

[Vish Ishaya (vishvananda)]

I see the following potential levels:

a) disable the extension but leave code in place

b) remove the exension completely but leave other code

c) remove all code but db

d) remove all code and db and migrate the tables out.

I'm ok with anyithing up to d). I think removing tables is dangerous and it also prevents zadara from shipping separately if need be because the db calls are still there

[Thierry Carrez (ttx)]

I am for (c)

This asks the question of how to ship database schema bits along with code needing it, rather than centrally...

Do we know how that VSA-broken situation happened exactly ? A change badly communicated, unindentified lack of maintenance and/or absence of tests ?

[Joe Gordon (jogo)]

I am for (c) as well.

[Jesse Andrews (anotherjesse)]

do we know intentions from the original contributor?

[Brian Waldon (bcwaldon)]

Going with option c. Jesse, there has been no attempt to fix the code from what I've seen.

[Vladimir Popovski (vladimir.p)]

Hi All,

Just saw this item & wrote a reply to ML.

Is there anything in particular broken in VSA code? Or do you mean that it is not useful?
We are using pure Diablo/stable in one of our environments and it is completely functional.

As I explained in my ML reply, we were planning to contribute all latest updates closer to Folsom.
But if at least this basic code will be removed it will be twice harder to perform a merge (especially if DBs will be removed).

I would vote for option A (for sure :-)).

Please let us know what should be done from our side in order to leave code as is.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/5377
Committed: http://github.com/openstack/nova/commit/a3bab242db16d036a415aa6ce3e95803b001bcc6
Submitter: Jenkins
Branch: master

commit a3bab242db16d036a415aa6ce3e95803b001bcc6
Author: Brian Waldon <email address hidden>
Date: Wed Mar 14 17:24:07 2012 -0700

    Remove Virtual Storage Array (VSA) code

    * Remove core vsa code (api, manager, drivers)
    * Remove nova-vsa executable
    * Remove OpenStack Compute API v2 vsa extension
    * Remove vsa scheduler
    * Remove vsa db api methods
    * Remove Zadara volume driver
    * Do not migrate out any existing data
    * Fixes bug 954490

    Change-Id: Idab3d60796d5edbc23ef9f0887fcc1af558c6215