Update TODO/FEATURE item list
This patch updates TODO.rst and FEATURE.rst based on the discussion in Tokyo meetup. The backlogs of Liberty cycle are picked up and some TODO items which are in long-term plan are moved from TODO.rst to FEATURES.rst. Change-Id: I799deb7adb3abbe066ac92f0f2cdbd0acc4265d3
This commit is contained in:
yanyanhu
parent
b47a2342df
commit
94feff4d51
101
FEATURES.rst
101
FEATURES.rst
|
|
@ -14,10 +14,19 @@ 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
|
||||
-------------
|
||||
|
||||
Support 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 coming burst of workloads.
|
||||
|
||||
|
||||
Event Listener
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -46,15 +55,19 @@ 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.
|
||||
Multi-cloud Support
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In some case, user could have the demand to create/scale cluster cross different
|
||||
clouds. Therefore, Senlin is supposed to have the ability to manage nodes which
|
||||
span cross multiple clouds within the same cluster. Support from both profile
|
||||
and policy layers are necessary for providing this ability.
|
||||
|
||||
|
||||
User Defined Actions
|
||||
|
|
@ -66,14 +79,6 @@ 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
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -99,6 +104,19 @@ potential tradeoff is to introduce an option for users to customize the size
|
|||
of batches when large number of DB requests pouring in.
|
||||
|
||||
|
||||
API versioning support
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This support can help to improve the stability and compatibility of Senlin API
|
||||
interface. We can learn some experience from what Nova has done for providing
|
||||
API version control.
|
||||
|
||||
|
||||
------------
|
||||
Low Priority
|
||||
------------
|
||||
|
||||
|
||||
Use Barbican to Store Secrets
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -124,9 +142,13 @@ necessarily have control over the admin plane, he or she does have a right to
|
|||
express their requirements in an abstract manner.
|
||||
|
||||
|
||||
------------
|
||||
Low Priority
|
||||
------------
|
||||
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.
|
||||
|
||||
|
||||
Vertical Scaling
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
|
@ -179,14 +201,6 @@ 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 coming burst of workloads.
|
||||
|
||||
|
||||
Interaction with Congress
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -201,3 +215,44 @@ 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.
|
||||
|
||||
|
||||
Run Senlin API under Apache
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add support to have Senlin API run under Apache.
|
||||
|
||||
|
||||
Baremetal Support
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
Managing baremetal cluster is a very common requirement from user. It is
|
||||
reasonable for Senlin to support it by talking with service like Ironic.
|
||||
|
||||
|
||||
Container/Docker support
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Using Senlin to manage Container/Docker cluster is possible. We should
|
||||
provide related support for users who have this requirement.
|
||||
|
||||
|
||||
TOSCA support
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Provide TOSCA support in Senlin(maybe reuse heat-translator/tosca-parser?)
|
||||
|
||||
|
||||
Versioned Object Support
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
oslo.versionedobjects is a lib provides a generic versioned object model that
|
||||
is RPC-friendly, with inbuilt serialization, field typing, and remotable method
|
||||
calls. We can use it to promote the upgrading capatibility of Senlin service.
|
||||
|
||||
|
||||
Dynamic Plugin Loading
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Design and implement dynamic plugin loading mechanism that allows loading
|
||||
plugins from any paths.
|
||||
|
|
|
|||
139
TODO.rst
139
TODO.rst
|
|
@ -1,17 +1,61 @@
|
|||
Senlin TODO Item List
|
||||
=====================
|
||||
This document records all workitems the team want to finish in a short-term
|
||||
(usually a development cycle which lasts 6 month). All jobs listed here are NOT
|
||||
in working progress which means developers can pick up any workitem they are
|
||||
interested in if they do have enough time to work on it. Developer should file
|
||||
a BluePrint in the launchpad to give a detailed description about their plan after
|
||||
deciding to work on a specific item. A patch should be proposed as well to remove
|
||||
related workitem from the TODO list after the BP gets approval.
|
||||
|
||||
|
||||
HIGH PRIORITY
|
||||
=============
|
||||
|
||||
API
|
||||
---
|
||||
- Make object creation/updating requests return code 202, since most of them
|
||||
are done asynchronously in Senlin.
|
||||
- Make object creation requests return both action_id and a location header set
|
||||
to the URI of the resource to be created. This is a requirement from API WG.
|
||||
- Correctly use 400 and 404 resp code following the guide from API WG.
|
||||
https://review.openstack.org/#/c/221163/
|
||||
- Find and fill gaps with API-WG besides the one we already identified.
|
||||
|
||||
ENGINE
|
||||
------
|
||||
- Lock breaker in multi-engine environment to pevent objects being locked by
|
||||
dead engine.
|
||||
|
||||
POLICY
|
||||
------
|
||||
- Investigate the impact of node-create and node-delete on certain policies.
|
||||
- Implement a placement policy which supports cross-az/region node creation
|
||||
with a simple algorithm. [Xinhui, Qiming]
|
||||
- Implement a deletion policy that supports cross-az/region node deleting.
|
||||
- Investigate the impact of node-create and node-delete on certain policies.
|
||||
|
||||
PROFILE
|
||||
-------
|
||||
- Enable node update support for Nova server. [Yanyan Hu]
|
||||
Receiver
|
||||
--------
|
||||
- Provide another abstraction layer to generalize the design of receiver in
|
||||
Senlin. Although we only support receiver type of webhook in current stage,
|
||||
we do have the plan to support more receiver types like message queue.
|
||||
|
||||
Health Management
|
||||
-----------------
|
||||
- Provide an option for user to define the threshold of cluster health status
|
||||
classification.
|
||||
- Support do_check/do_recover in profiles.
|
||||
- Support cluster/node health status refresh and expose API interface: By
|
||||
default, 'cached' health status of Senlin objects will be provided to user.
|
||||
Object health status will only be refreshed when user requests initiatively.
|
||||
|
||||
TEST
|
||||
----
|
||||
- Add unit test for engine/parser
|
||||
- Complete unit test of senlinclient
|
||||
|
||||
DOC
|
||||
-----
|
||||
- Provide document(or docstring) for policy data passing for developers.
|
||||
- Provide documentation for existing policies.
|
||||
|
||||
|
||||
MIDDLE PRIORITY
|
||||
|
|
@ -26,55 +70,33 @@ API
|
|||
- According to the proposal (https://review.openstack.org/#/c/234994/),
|
||||
actions are to follow a guideline. We may need to revise our actions API
|
||||
and those related to asynchronous operations.
|
||||
- Add support to replace a cluster node with another node
|
||||
- Make object creation requests return code 202, since most creation
|
||||
are done asynchronously in Senlin.
|
||||
- Make object creation requests return a location header set to the URI
|
||||
of the resource to be created. This is a requirement from API WG.
|
||||
- API resource names should not include underscores. A guideline from API
|
||||
WG.
|
||||
- Add support to have Senlin API run under Apache.
|
||||
|
||||
DB
|
||||
--
|
||||
- The action data model is missing 'scheduled_start' and 'scheduled_stop'
|
||||
fields, we may need these fields for scheduled action execution.
|
||||
|
||||
ENGINE
|
||||
------
|
||||
- Add configuration option to enforce name uniqueness. There are reasonable
|
||||
requirements for cluster/node names to be unique within a project. This
|
||||
should be supported, maybe with the help from a name generator? [Yanyan Hu]
|
||||
|
||||
- Design and implement dynamical plugin loading mechanism that allows
|
||||
loading plugins from any paths
|
||||
|
||||
- Provide support to oslo.notification and allow nodes to receive and react
|
||||
to those notifications accordingly.
|
||||
[https://ask.openstack.org/en/question/46495/heat-autoscaling-adaptation-actions-on-existing-servers/]
|
||||
|
||||
- Allow actions to be paused and resumed.
|
||||
This is important for some background actions such as health checking
|
||||
|
||||
- Add support to template_url for heat stack profile
|
||||
Note: if template and template_url are both specified, use template
|
||||
Need to refer to heat api test for testing heat profile
|
||||
|
||||
- Revise start_action() in scheduler module so that it can handle cases when
|
||||
action_id specified is None. When ``action_id`` parameter is None, it
|
||||
means that the scheduler will pick a suitable READY action for execution.
|
||||
|
||||
- Add event logs wherever needed. Before that, we need a design on the
|
||||
criteria for events to be emitted. [Partially done]
|
||||
|
||||
OSLO
|
||||
----
|
||||
- Add support to oslo_versionedobjects
|
||||
PROFILE
|
||||
-------
|
||||
- Add support to template_url for heat stack profile. If template and template_url
|
||||
are both specified, use template. Need to refer to heat api test for testing heat
|
||||
profile.
|
||||
|
||||
|
||||
POLICY
|
||||
------
|
||||
- Scaling policy allowng a cluster to scale to existing nodes
|
||||
- Health policy
|
||||
- Provide support for watching all objects we created on behalf of users, like
|
||||
loadbalancer which is created when attaching lb policy.
|
||||
- Leverage other monitoring service for object health status monitoring.
|
||||
|
||||
|
||||
DB
|
||||
--
|
||||
- Add db purge (senlin-manage) for deleting old db entries, especially for events
|
||||
and actions because they accumulate very fast.
|
||||
|
||||
|
||||
LOW PRIORITY
|
||||
|
|
@ -82,16 +104,35 @@ LOW PRIORITY
|
|||
|
||||
API
|
||||
---
|
||||
|
||||
- Allow forced deletion of objects (cluster, node, policy, profile). The
|
||||
current problem is due to the limitations of the HTTP DELETE requests. We
|
||||
need to investigate whether a DELETE verb can carry query strings.
|
||||
|
||||
TEST
|
||||
----
|
||||
- Add test case to engine/parser
|
||||
ENGINE
|
||||
------
|
||||
- Allow actions to be paused and resumed. This is important for some background
|
||||
actions such as health checking.
|
||||
- Add support to replace a cluster node with another node.
|
||||
- Provide support to oslo.notification and allow nodes to receive and react
|
||||
to those notifications accordingly.
|
||||
[https://ask.openstack.org/en/question/46495/heat-autoscaling-adaptation-actions-on-existing-servers/]
|
||||
|
||||
POLICY
|
||||
------
|
||||
- Scaling policy: allow a cluster to scale to existing nodes.
|
||||
- Batching policy: create batchs for node creation/deletion/update.
|
||||
|
||||
Trigger
|
||||
-------
|
||||
- Monasca alarm based triggers.
|
||||
- Zaqar queue based triggers.
|
||||
|
||||
EVENT
|
||||
-----
|
||||
- Complete event log generation.
|
||||
|
||||
DOC
|
||||
-----
|
||||
- Provide a sample conf file for customizing senlin options
|
||||
- Provide documentation for all policies
|
||||
- Provide a sample conf file for customizing senlin options.
|
||||
- Give a sample end-to-end story to demonstrate how to use Senlin for autoscaling
|
||||
scenario.
|
||||
|
|
|
|||
Loading…
Reference in New Issue