~devstack-core/devstack/github : contents of FUTURE.rst at revision 3167

~devstack-core/devstack/github : (revision 3167)

=============
 Quo Vadimus
=============

Where are we going?

This is a document in Devstack to outline where we are headed in the
future. The future might be near or far, but this is where we'd like
to be.

This is intended to help people contribute, because it will be a
little clearer if a contribution takes us closer to or further away to
our end game.

==================
 Default Services
==================

Devstack is designed as a development environment first. There are a
lot of ways to compose the OpenStack services, but we do need one
default.

That should be the Compute Layer (currently Glance + Nova + Cinder +
Neutron Core (not advanced services) + Keystone). It should be the
base building block going forward, and the introduction point of
people to OpenStack via Devstack.

================
 Service Howtos
================

Starting from the base building block all services included in
OpenStack should have an overview page in the Devstack
documentation. That should include the following:

- A helpful high level overview of that service
- What it depends on (both other OpenStack services and other system
  components)
- What new daemons are needed to be started, including where they
  should live

This provides a map for people doing multinode testing to understand
what portions are control plane, which should live on worker nodes.

Service how to pages will start with an ugly "This team has provided
no information about this service" until someone does.

===================
 Included Services
===================

Devstack doesn't need to eat the world. Given the existence of the
external devstack plugin architecture, the future direction is to move
the bulk of the support code out of devstack itself and into external
plugins.

This will also promote a more clean separation between services.

=============================
 Included Backends / Drivers
=============================

Upstream Devstack should only include Open Source backends / drivers,
it's intent is for Open Source development of OpenStack. Proprietary
drivers should be supported via external plugins.

Just being Open Source doesn't mean it should be in upstream Devstack
if it's not required for base development of OpenStack
components. When in doubt, external plugins should be used.

========================================
 OpenStack Services vs. System Services
========================================

ENABLED_SERVICES is currently entirely too overloaded. We should have
a separation of actual OpenStack services that you have to run (n-cpu,
g-api) and required backends like mysql and rabbitmq.

===========================
 Splitting up of Functions
===========================

The functions-common file has grown over time, and needs to be split
up into smaller libraries that handle specific domains.

======================
 Testing of Functions
======================

Every function in a functions file should get tests. The devstack
testing framework is young, but we do have some unit tests for the
tree, and those should be enhanced.

==============================
 Not Co-Gating with the World
==============================

As projects spin up functional test jobs, Devstack should not be
co-gated with every single one of those. The Devstack team has one of
the fastest turn arounds for blocking bugs of any Open Stack
project.

Basic service validation should be included as part of Devstack
installation to mitigate this.

============================
 Documenting all the things
============================

Devstack started off as an explanation as much as an install
script. We would love contributions to that further enhance the
comments and explanations about what is happening, even if it seems a
little pedantic at times.

2851.2.1 by Sean Dague Document where we are going	1	=============
	2	Quo Vadimus
	3	=============
	4
	5	Where are we going?
	6
	7	This is a document in Devstack to outline where we are headed in the
	8	future. The future might be near or far, but this is where we'd like
	9	to be.
	10
	11	This is intended to help people contribute, because it will be a
	12	little clearer if a contribution takes us closer to or further away to
	13	our end game.
	14
	15	==================
	16	Default Services
	17	==================
	18
	19	Devstack is designed as a development environment first. There are a
	20	lot of ways to compose the OpenStack services, but we do need one
	21	default.
	22
	23	That should be the Compute Layer (currently Glance + Nova + Cinder +
	24	Neutron Core (not advanced services) + Keystone). It should be the
	25	base building block going forward, and the introduction point of
	26	people to OpenStack via Devstack.
	27
	28	================
	29	Service Howtos
	30	================
	31
	32	Starting from the base building block all services included in
	33	OpenStack should have an overview page in the Devstack
	34	documentation. That should include the following:
	35
	36	- A helpful high level overview of that service
	37	- What it depends on (both other OpenStack services and other system
	38	components)
	39	- What new daemons are needed to be started, including where they
	40	should live
	41
	42	This provides a map for people doing multinode testing to understand
	43	what portions are control plane, which should live on worker nodes.
	44
	45	Service how to pages will start with an ugly "This team has provided
	46	no information about this service" until someone does.
	47
	48	===================
	49	Included Services
	50	===================
	51
	52	Devstack doesn't need to eat the world. Given the existence of the
	53	external devstack plugin architecture, the future direction is to move
	54	the bulk of the support code out of devstack itself and into external
	55	plugins.
	56
	57	This will also promote a more clean separation between services.
	58
	59	=============================
	60	Included Backends / Drivers
	61	=============================
	62
	63	Upstream Devstack should only include Open Source backends / drivers,
	64	it's intent is for Open Source development of OpenStack. Proprietary
65	drivers should be supported via external plugins.
66
67	Just being Open Source doesn't mean it should be in upstream Devstack
68	if it's not required for base development of OpenStack
69	components. When in doubt, external plugins should be used.
70
71	========================================
72	OpenStack Services vs. System Services
73	========================================
74
75	ENABLED_SERVICES is currently entirely too overloaded. We should have
76	a separation of actual OpenStack services that you have to run (n-cpu,
77	g-api) and required backends like mysql and rabbitmq.
78
79	===========================
80	Splitting up of Functions
81	===========================
82
83	The functions-common file has grown over time, and needs to be split
84	up into smaller libraries that handle specific domains.
85
86	======================
87	Testing of Functions
88	======================
89
90	Every function in a functions file should get tests. The devstack
91	testing framework is young, but we do have some unit tests for the
92	tree, and those should be enhanced.
93
94	==============================
95	Not Co-Gating with the World
96	==============================
97
98	As projects spin up functional test jobs, Devstack should not be
99	co-gated with every single one of those. The Devstack team has one of
100	the fastest turn arounds for blocking bugs of any Open Stack
101	project.
102
103	Basic service validation should be included as part of Devstack
104	installation to mitigate this.
105
106	============================
107	Documenting all the things
108	============================
109
110	Devstack started off as an explanation as much as an install
111	script. We would love contributions to that further enhance the
112	comments and explanations about what is happening, even if it seems a
113	little pedantic at times.