Save mapping of which device tenants are stored on in v1/v2

[ghost]

We need to know which device a tenant "lives on" for scaling purposes.

• [ ] Make migration for database table to store which device each tenant is on
• [ ] Initially populate table with the tenant's current device

[Cedev]

We need to store which device each loadbalancer/vip is on. Break the indirect dependency

loadbalancer ---> tenant ---> device
              |           ^ hash of tenant id
              ^ neutron table

And replace it with

loadbalancer ---> device
              ^ new table

(The loadbalancer will still know which tenant it belongs to)

[Cedev]

The plan is to make one polymorphic table for loadbalancers (A10_SLB) and another one for devices (A10_DEVICES). In the alembic migrations there'll be separate branches for tables that depend on lbaas v1 and lbaas v2. The SQL alchemy classes for the version specific models will only be defined if there's support for that version.

A10_DEVICES will need a new name; it's used in another one of our products.

[Cedev]

To do:

• [ ] Rename device_key to configuration_key
• [x] Make migration to populate existing appliances (devices)
• [x] Make migration to populate appliance (device) for existing lbaas v1 vips
• [x] Make migration to populate appliance (device) for existing lbaas v2 loadbalancers
• [x] Create appliances as needed
• [x] Create a10_slb_v1 when handling a v1 vip creation
• [x] Delete the a10_slb_v1 when handling a v1 vip removal
• [x] Create a10_slb_v2 when handling a v2 loadbalancer creation
• [x] Delete the a10_slb_v2 when handling a v2 loadbalancer removal
• [ ] patch whatever vip code is checking the hash to get the device to instead get it from the model (will still use the hash to pick devices for new vips)
• [x] patch whatever loadbalancer code is checking the hash to get the device to instead get if from the model (will still use the hash to pick devices for new loadbalancers)
• [x] Make the A10ApplianceConfigured model present the data from the configuration (might be a separate story)
• [x] Make a working, simple cli
• [x] Add a cli command to run the upgrades for all the branches, skipping and reporting the ones that couldn't be upgraded
• [ ] Test that migrations work regardless of order (head first then lbaas head, head partway then lbaas head, etc)

[Cedev]

To do the migration we need to load the real configuration. I tried hacking one together by making an A10OpenstackLBV1(None), but that doesn't get the provider name so we don't know which vips are ours. We're going to have to figure out how to load the real deal, enumerate the providers, and check to see if they are the a10 provider we're working with.

[Cedev]

The following demonstrates getting the (almost) real configuration for the drivers. It doesn't provide a plugin and doesn't import all of the set up for oslo configuration that is set up when a driver loads for real.

import neutron.plugins.common.constants as constants
import neutron.services.service_base as service_base
from oslo_config import cfg

cfg.CONF(project='neutron')

lbv2 = service_base.load_drivers(constants.LOADBALANCERV2,None)
print lbv2
print lbv2[0][lbv2[1]].a10.hooks.select_device('012-345')

The migrations are going to use this mechanism to get the drivers and their provider names.

[Cedev]

The cli unfortunately includes a workaround for alembic issue 336.

[Cedev]

Blocked by #122