a1b5eda8dc
Added a new feature request -- customizable batch size when doing large amount of operations at the same time. Change-Id: I3c3409fba273d2f0cf642df0ebbb4f472c053505
194 lines
6.4 KiB
ReStructuredText
194 lines
6.4 KiB
ReStructuredText
Senlin Feature Request Pipeline
|
|
===============================
|
|
|
|
This document records the feature requests the developer team has received and
|
|
considered. This document SHOULD NOT be treated as a replacement of the
|
|
blueprints (or specs) which already accompanied with a design. The feature
|
|
requests here are meant to be a pipeline for mid-term goals that Senlin should
|
|
strive to achieve. Whenever a feature can be implemented with a practical
|
|
design, the feature should be moved to a blueprint (and/or specs) review.
|
|
|
|
This document SHOULD NOT be treated as a replacement of the `TODO` file the
|
|
development team is maintaining. The `TODO` file records actionable work items
|
|
that can be picked up by any developer who is willing to do it, while this
|
|
document records more general requirements that needs at least a draft design
|
|
before being worked on.
|
|
|
|
-------------
|
|
High Priority
|
|
-------------
|
|
|
|
Event Listener
|
|
^^^^^^^^^^^^^^
|
|
|
|
To make Senlin responsive to events published by other OpenStack services, an
|
|
event subscriber is needed so that Senlin can receive notifications from
|
|
sources such as Ceilometer, Nova, or Zaqar.
|
|
|
|
This is of a high priority because Senlin needs it as one of its HA solutions.
|
|
|
|
|
|
Scavenger Process
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
Senlin needs a scavenger process that runs as a background daemon. It is
|
|
tasked with cleansing database for old data, e.g. event records. Its behavior
|
|
must be customizable because users may want the old records to be removed or
|
|
to be archived in a certain way.
|
|
|
|
|
|
Fault Tolerance
|
|
^^^^^^^^^^^^^^^
|
|
|
|
Senlin in most cases will be managing clusters with nodes distributed
|
|
somewhere. One problems inherent to such a distributed architecture is about
|
|
partial failures, communication latencies, concurrency, consistency etc. There
|
|
are hardware/software failures expected. Senlin must remain operational in the
|
|
face of such failures.
|
|
|
|
---------------
|
|
Middle Priority
|
|
---------------
|
|
|
|
Horizon Plugin
|
|
^^^^^^^^^^^^^^
|
|
|
|
Senlin needs a plug-in at the OpenStack dashboard side so that users can
|
|
interact with the service in a more user-friendly way.
|
|
|
|
|
|
User Defined Actions
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Actions in Senlin are mostly built-in ones at present. There are requirements
|
|
to incorporate Shell scripts and/or other structured software configuration
|
|
tools into the whole picture. One of the option is to provide a easy way for
|
|
Senlin to work with Ansible, for example.
|
|
|
|
|
|
CoreOS based Container Support
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
To Senlin, CoreOS is just another VM image. However, CoreOS provides some
|
|
builtin support to Container/Docker and it provides clustering facility for
|
|
user applications.
|
|
|
|
|
|
Define and Enforce Quotas
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
There is a potential request to limit how many clusters a user can create, how
|
|
large a cluster can become.
|
|
|
|
|
|
Event Notification
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
Event notification is a feature that enables an external tool to subscribe to
|
|
events sent from Senlin when interesting things happen. One option is to use
|
|
the messaging service provided by the Zaqar project.
|
|
|
|
|
|
Customizable Batch Processing
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
An important non-functional requirement for Senlin is the scale of clusters it
|
|
can handle. We will strive to make it handle large scale ones, however that
|
|
indicates that we need to improve DB accesses in case of heavy loads. One
|
|
potential tradeoff is to introduce an option for users to customize the size
|
|
of batches when large number of DB requests pouring in.
|
|
|
|
|
|
Use Barbican to Store Secrets
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Currently, Senlin uses the `cryptography` package for data encryption and
|
|
decryption. There should be support for users to store credentials using the
|
|
Barbican service, in addition to the current solution.
|
|
|
|
|
|
Use VPNaaS to Build Cross-Region/Cross-Cloud
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
When buidling clusters that span more than one region or cloud, there are
|
|
requirements to place all cluster nodes on the same VPN so that workloads can
|
|
be distributed to the nodes as if they sit on the same network.
|
|
|
|
|
|
Make Use of Nova ServerGroup API
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
When creating a cluster of Nova servers, Senlin needs to work with Nova and its
|
|
scheduler to provide sophisticated scheduling decisions. While a user do not
|
|
necessarily have control over the admin plane, he or she does have a right to
|
|
express their requirements in an abstract manner.
|
|
|
|
|
|
------------
|
|
Low Priority
|
|
------------
|
|
|
|
Replace Green Threads with Python Threading
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Senlin is now using green threads (eventlets) for async executions. The
|
|
eventlets execution model is not making the use of multi-processing platforms
|
|
in an efficient way. Senlin needs a scalable execution engine, so native
|
|
multi-threading is needed.
|
|
|
|
|
|
Metrics Collection
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
Senlin needs to support metric collections about the clusters and nodes it
|
|
manages. These metrics should be collectable by the ceilometer service, for
|
|
example.
|
|
|
|
|
|
AWS Compatible API
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
There are requirements for Senlin to provide a AWS compatible API layer so
|
|
that existing workloads can be deployed to Senlin and AWS without needing to
|
|
change a lot of code or configurations.
|
|
|
|
|
|
Integration with Mistral
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
There are cases where the (automated) operations on clusters and nodes form a
|
|
workflow. For example, an event triggers some actions to be executed in
|
|
sequence and those actions in turn triggers other actions to be executed.
|
|
|
|
|
|
Support to Suspend/Resume Operations
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
A user may want to suspend/resume a cluster or an individual node. Senlin
|
|
needs to provide a generic definition of 'suspend' and 'resume'. It needs to
|
|
be aware of whether the profile and the driver support such operations.
|
|
|
|
|
|
Support to Scheduled Actions
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is a request to trigger some actions at a specified time. One typical use
|
|
case is to scale up a cluster before weekend or promotion season as a
|
|
preparation for the comming burst of workloads.
|
|
|
|
|
|
Interaction with Congress
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is of low priority because Senlin needs a notification mechanism in place
|
|
before it can talk to Congress. The reason to interact with Congress is that
|
|
there could be enterprise level policy enforcement that Senlin has to comply
|
|
to.
|
|
|
|
|
|
Integration with Tooz
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
There is potential requirement to do a better coordination between nodes in a
|
|
cluster. That is where the Tooz project can be leveraged.
|