92aa310652
This patch also ignore "queues" setences. Change-Id: If05d8238a1c92b336faab037b656ca5d5bbd3d49
164 lines
5.4 KiB
ReStructuredText
164 lines
5.4 KiB
ReStructuredText
..
|
|
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
|
|
|