File: FEATURES.rst

package info (click to toggle)
senlin 6.0.0-1
  • links: PTS, VCS
  • area: main
  • in suites: buster
  • size: 6,872 kB
  • sloc: python: 66,932; sh: 588; makefile: 196
file content (284 lines) | stat: -rw-r--r-- 9,529 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
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
~~~~~~~~~~~~~

TOSCA support
-------------

Provide TOSCA support in Senlin (maybe reuse heat-translator/tosca-parser?)


Advanced Container Clustering
-----------------------------

Container cluster management:

- Scheduling
- Networking/Storage
- APIs/Operations
- Security issues
- Dependencies


Better Versioning for Profile/Policy
------------------------------------

Profile/Policy schema could vary over time for properties being added or
deprecated. Versioning support is important for keeping backward
compatibility when profile/policy evolve.


Role-specific Profiles
----------------------

There are needs to have nodes of the same role to share a common profile while
nodes of different roles having different profiles. The pre-condition for this
is that the profile-types match.


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.


Scaling to Existing Nodes
-------------------------

[Conclusion from Austin: https://etherpad.openstack.org/p/newton-senlin-as]

Senlin can improve scale-out operation so that it can add existing nodes to
a cluster when doing scale-out. We are not intended to scale to nodes not
created by Senlin.


Adoption of Nodes
-----------------

There have been requirements on adopting existing resources (e.g. nova
servers) to be managed by Senlin.


Middle Priority
~~~~~~~~~~~~~~~

Access Control
--------------

Currently, all access to Senlin objects like cluster, profile are project_safe
by default. This is for preventing user manipulating resources belong to other
users. However, sharing resource between different users/projects with limited
privilege(e.g. read-only, read-write) is also a very reasonable demand in many
cases. Therefore, we may need to provide access permission control in Senlin to
support this kind of requirement.


Blue-Green Deployment
---------------------

Support to deploy environments using blue-green deployment pattern.
http://martinfowler.com/bliki/BlueGreenDeployment.html


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.


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.


Support to Bare-metal
---------------------

Managing baremetal cluster is a very common requirement from user. It is
reasonable for Senlin to support it by talking with service like Ironic.


Improve health schedule
-----------------------
Schedule which engine to handle which clusters health registries can be
improved. For example:1. When first engine start it will run all health
registries. 2. When the other engine start it can send a broadcast
message which carried its handling capacity and said it want to assume
some health registries.


Host Fencing Support
--------------------
To ensure a seemingly dead node is actually dead, all HA solutions need a way
to kill a node for sure. Senlin is no exception here. We have support to force
delete a VM instance already. The need is a mechanism to kill a failed host.


LB HealthMonitor based failure detection
----------------------------------------
Ideally, Senlin could rely on the LBaaS service for node failure detection
rather than reinventing the wheel. However, LBaaS (Octavia) is not fixing the
obvious bug.
Another option is to have LBaaS emit events when node failures are detected.
This proposal has failed find its way into the upstream.
When the upstream project (Octavia) has such features, we can enable them from
Senlin side.


Low Priority
~~~~~~~~~~~~

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 an easy way for
Senlin to work with Ansible, for example.


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 building 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.


Vertical Scaling
----------------

Though Senlin is mainly concerns about the horizontal scaling in/out support,
there are possibilities/requirements to scale nodes in the vertical direction.
Vertical scaling means automatically adding compute/storage/network resources
to cluster nodes. Depending on the support from corresponding services, this
could be explored.


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 collectible by the ceilometer service, for
example.


AWS Compatible API
------------------

There are requirements for Senlin to provide an 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.


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.


Investigation of Tooz
---------------------

There is requirement to manage multiple senlin-engine instances in a
distributed way. Or, we can use a variant of DLM to manage cluster membership.
E.g. use redis/zookeeper to build clusters in their sense so that when the
cluster membership changes, we may possibly receive a notification. This would
be helpful for cluster health management.

Tooz is the promised focal point in this field, generalizing the many backends
that we don't want to care about. This TODO item is about two things:

#. Whether Tooz does provide a reliable membership management infra?
#. Is there a comparison between zookeeper and redis for example.


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.


Dynamic Plugin Loading
----------------------

Design and implement dynamic plugin loading mechanism that allows loading
plugins from any paths.