Merge "Improve storage capabilities"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
d93518d175
|
|
@ -0,0 +1,126 @@
|
|||
..
|
||||
This template should be in ReSTructured text. The filename in the git
|
||||
repository should match the launchpad URL, for example a URL of
|
||||
https://blueprints.launchpad.net/zaqar/+spec/awesome-thing should be named
|
||||
awesome-thing.rst.
|
||||
|
||||
Please do not delete any of the sections in this
|
||||
template. If you have nothing to say for a whole section, just write: None
|
||||
|
||||
For help with syntax, see http://sphinx-doc.org/rest.html
|
||||
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
=============================
|
||||
Expose storage capabilities
|
||||
=============================
|
||||
|
||||
Flavors allow operators to expose some of the internal storage capabilities without giving the exact details of how the system is configured. As of now, the operators has total control over what capabilities are exposed to the user regardeless on whether these capabilities are indeed guaranteed or valid. A `capability` is a feature that is either specific to the storage or to Zaqar - durable, fifo, in-memory, for example - and they can be enabled/exposed in a per-flavor basis allowing end-users to choose the best flavor for a specific queue.
|
||||
|
||||
https://blueprints.launchpad.net/zaqar/+spec/expose-storage-capabilities
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Flavors are very powerful when it comes to give choices to end-users without taking control out from operators. However, there's no way for operators to know what capabilities each storage driver has, which makes this feature completely custom to whatever the operator thinks makes more sense.
|
||||
|
||||
It's important to support operators on the choice of what features are exposed to the end-users through the API by making it clear which are supported by the drivers that have been deployed. Moreover, this is also important for doing a proper capacity planning based on the use-cases the service is trying to support.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Capabilities
|
||||
------------
|
||||
|
||||
This change request proposes defining a set of internal `capabilities` and a way for storage drivers to expose which capabilities are supported so that operators may know in advance what a flavor would support and what storage drivers they may need.
|
||||
|
||||
The set of internal capabilities includes:
|
||||
|
||||
- FIFO
|
||||
- AOD (At least once delivery)
|
||||
- high-throughput
|
||||
- claims
|
||||
|
||||
Exposing Capabilities
|
||||
---------------------
|
||||
|
||||
This capabilities should be exposed by the storage driver iff supported. This spec proposes adding a new class method to the base class called `capabilities` that should return a set with a list of supported `capabilities`. The capabilities returned in this set cannot be custom, which means they must be supported internally.::
|
||||
|
||||
@six.add_metaclass(abc.ABCMeta)
|
||||
class DataDriverBase(DriverBase):
|
||||
...
|
||||
|
||||
@property
|
||||
def capabilities(self):
|
||||
return self._CAPABILITIES
|
||||
|
||||
|
||||
Drivers Load
|
||||
------------
|
||||
|
||||
In addition to the above-mentioned changes, we also need a better way to load drivers based on the capabilities. That is, when drivers are loaded, it's necessary to pass down to the driver the capabilities that have been enabled per-flavor so that the driver itself can be specialized for some capabilities. In most of the cases, loading a driver will end up in always loading the same implementation. However, there are cases - FIFO, for example - where more specialized implementations may be needed depending on the storage. Therefore, instead of *always* loading the `DataDriver`, this spec proposes adding a new `get_driver` function that will let the storage itself load a driver according to the capabilities passed there.::
|
||||
|
||||
def get_driver(plane='data', capabilities=None):
|
||||
...
|
||||
|
||||
|
||||
This means we won't need to register neither `DataDriver`s nor `ControlDriver`s as `entry_points` but just the new `get_driver` function. This will allow storage driver's to expose fewer things as public API's. A variant for the above `get_driver` proposal would be.::
|
||||
|
||||
def get_driver(base=base.BaseDataDriver, capabilities=None):
|
||||
...
|
||||
|
||||
This way we can avoid giving 'names' to this planes and just ask what we need in terms of 'signature'. However, it makes loading the actual driver a bit more complex and it'll also duplicate some logic across different storage drivers.
|
||||
|
||||
Pools and Flavors
|
||||
-----------------
|
||||
|
||||
Flavors have support for capabilities. As of now, these capabilities
|
||||
are 100% custom. With the implementation of this spec, it'll be
|
||||
possible for flavors to know in advance what capabilities are
|
||||
supported based on the stores registered in the pool.
|
||||
|
||||
Pools, however, shouldn't allow storage drivers with different
|
||||
capabilities to co-exist under the same pool. That is to say that
|
||||
pools will have to verify the storage capabilities when new nodes are
|
||||
added to the pool and ensure that the capabilities supported by the
|
||||
new node are consistent with the rest of the nodes in the pool.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Keep it custom and do nothing.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
flaper87
|
||||
|
||||
Secondary assignee:
|
||||
vkmc
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion:
|
||||
K-1
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Define list of internal capabilities and document it
|
||||
* Add required abstractions to storage drivers to expose the supported capabilities
|
||||
* Let flavor's pass the capabilities down to the storage driver when it's being loaded.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
.. note::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
Loading…
Reference in New Issue