Legacy MySQL datastore is shown on datastore-list

[Edmond Kotowski]

Legacy MySQL is shown when calling trove datastore-list. Creating an instance with this datastore will cause the create call to fail. Some ideas for a fix would be to mark the database as active=False or upgrade the datastore list call to not return back the "Legacy MySQL" datastore.

+--------------------------------------+--------------------+
| ID | Name |
+--------------------------------------+--------------------+
| 10000000-0000-0000-0000-000000000001 | Legacy MySQL |
| 52abfff2-2d12-45bf-b764-04122bf20687 | mysql |
| 7e422d1a-7124-4958-95e3-facbea1d412e | Test_Datastore_1 |
| b58869c9-72c8-4747-b077-a7a19e4fd503 | Inactive_Datastore |
+--------------------------------------+--------------------+

[Amrith Kumar (amrith)]

isn't this the artifact of some test that setup a datastore and didn't delete it, or that this came out of "redstack kick-start mysql"?

[Edmond Kotowski (ekotowski)]

It comes from the migration script 019_datastore_fix.py in the method create_legacy_version. This is why I thought the cleanest fix would be to add a migration scripts that sets the Active flag to false so it won't show up when you call datastore-list.

Here is the a snippet from the 019_datastore.py:
def create_legacy_version(datastores_table,
                          datastore_versions_table,
                          image_id):
    insert(
        table=datastores_table,
        values=dict(id=LEGACY_DATASTORE_ID, name="Legacy MySQL")
    ).execute()

    insert(
        table=datastore_versions_table,
        values=dict(id=LEGACY_VERSION_ID,
                    datastore_id=LEGACY_DATASTORE_ID,
                    name="Unknown Legacy Version",
                    image_id=image_id,
                    packages="",
                    active=False,
                    manager="mysql")
    ).execute()

    return LEGACY_VERSION_ID

[Auston McReynolds (amcrn)]

there be dragons here.

it's quite possible the deployer had trove deployed pre-datastores, which means if you flipped active=0, datastore-list would return nothing. when we did this upgrade, we simply changed the name from "Legacy MySQL" to "mysql" and that was that (the instance provisioning still worked).

as to why the name "Legacy MySQL" was chosen: not sure.

[Edmond Kotowski (ekotowski)]

Auston: We do think this a bug right? When we deploy through devstack with trove we shouldn't have a Legacy MySql datastore listed that we are unable to create an instance with. Do we think the fix would be to set the Legacy MySQL datastore to active=0 through a migration script?

[Auston McReynolds (amcrn)]

"We do think this a bug right? When we deploy through devstack with trove we shouldn't have a Legacy MySql datastore listed that we are unable to create an instance with."

this is definitely a bug if it surfaces in devstack.

however, to ensure the fix doesn't negatively impact someone doing a production upgrade, the following test is necessary:

* build a trove instance with 018_ being the latest version, wait til active.
* do a db_upgrade.
* if datastore-list returns nothing, the fix is incorrect.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/138563

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/138563
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=a6358494d1cc17f7b56ff8e515be88e67cd428dc
Submitter: Jenkins
Branch: master

commit a6358494d1cc17f7b56ff8e515be88e67cd428dc
Author: Edmond Kotowski <email address hidden>
Date: Tue Dec 2 14:10:49 2014 -0800

    Legacy MySQL datastore is shown on datastore-list

      On the 019_datastore_fix.py migration script the upgrade method was
    calling the has_instances_wo_datastore_version as a function pointer
    instead of passing the instance_table in and calling the function. This
    meant the if block was always true because it was just checking if the
    function exists and the create_legacy_version method was called everytime
    causing the "Legacy MySQL" datastore to be inserted even if there was no
    legacy trove instances. Now inject the instace_table into the
    has_instances_wo_datastore_version and everything works as expected.

      Updated the datastore integration tests to not rely on the Legacy MySQL
    datastore to exist by using the 10000000-0000-0000-0000-000000000001 GUID.
    Instead the test now asserts against the data_store by the name
    "Test_Datastore_1" which is the datastore the integration test
    intended to validate against.

    Closes-Bug: 1396427
    Change-Id: Ifff33a962cc8d6ea150f6408d63b81412e196939