Initial version of FEATURES file

This file is meant to be a pool for upcoming feature requests to Senlin.
The development team will maintain it until the high/middle priorty ones
are done or there are alternatives to maintain such a feature request
list.

Change-Id: Ica99835b42a769bb14c0f729c7a2249d8ca4925d

FEATURES.rst

@@ -0,0 +1,157 @@
+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.
+
+
+---------------
+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.
+
+
+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.
+
+
+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
+------------
+
+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.