Adds a ProviderConfig class method that can be called to get
the config schema for the common config options in a Provider.
Drivers are modified to call this method.
Change-Id: Ib67256dddc06d13eb7683226edaa8c8c10a73326
Our driver code is in a less-than-ideal situation where each driver
is responsible for parsing config options that are common to all
drivers. This change begins to correct that, starting with ConfigPool.
It changes the driver API in the following ways:
1) Forces objects derived from ConfigPool to implement a load() method
that should call super's method, then handle loading driver specific
options from the config.
2) Adds a ConfigPool class method that can be called to get the config
schema for the common config options leaving drivers to have to only
define the schema for their own config options.
Other base config objects will be modeled after this pattern in
later changes.
Change-Id: I41620590c355cacd2c4fbe6916acfe80f20e3216
Pools within the same provider that have different labels are
attempting to handle requests for ALL labels defined within the provider.
This is due to change I61263f51be5e957de71d1e2dabaa7391bbe7bddf which
incorrectly changed from getting supported labels from per-pool to
per-provider. This modifies the getSupportedLabels() API to support
pools.
Change-Id: I7a0d472928c6b528f6faa6dd3b9cf1479874cb22
This is, like the drivers in zuul, designed to be a single instance
per driver that survives for the life of the process. It is used
to further instantiate driver-specific interfaces.
Here we have it return the config object for the driver (replacing
the previous system which loaded it from specific config files).
We also move the reset method from the ProviderConfig to the Driver
object. It's currently only used to clear a global os client config
object, so this better matches its lifecycle.
Change-Id: I1f5a7be9c597be842bfe4dbea8f153d7a96d7b9a
Rather than relying on inspection and loading classes from specific
filenames, ask each driver's Provider implementation to supply the
NodeRequestHandler instance for requests.
This is the first in a series of changes to remove all similar
indirection from the drivers in order to make them easier to
understand.
The test driver is moved out of the fixtures subdir to be a
"regular" driver because it now needs relative imports (provider
code needs to import the handler code).
Change-Id: Iad60d8bfe102d43b9fb1a1ff3ede13e4fa753572
David Shrewsbury