Add Compute Starter constellation
Entirely based on sdague's work here - Ie4aefe54a88aff9cebdf44e0e6c3f8ed95aa0d0e and template from johnthetubaguy's Scientific Computing constellation: Ia57aa41dd923d1fbc53512f5e10580d5575a4e5f proposes a new constellation to specify a small number of projects that are targeted at initial compute deploys by new operators. Change-Id: Ia57aa41dd923d1fbc53512f5e10580d5575a4e5e
This commit is contained in:
parent
429c50163e
commit
08962f9b51
|
@ -0,0 +1,17 @@
|
|||
==============
|
||||
Constellations
|
||||
==============
|
||||
|
||||
Constellations are a way of looking at OpenStack that gives users
|
||||
concrete approaches for getting started and developers a way to
|
||||
understand how projects get used together by our users.
|
||||
|
||||
When complete, it is expected that Constellations will include docs
|
||||
and automation specific to the described environment, including:
|
||||
a quick start install script, an operators guide and a
|
||||
consolidated API reference guide.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
starter
|
|
@ -0,0 +1,104 @@
|
|||
=============================
|
||||
Compute Starter Constellation
|
||||
=============================
|
||||
|
||||
This constellation focuses on how OpenStack is used for a Compute oriented
|
||||
OpenStack cloud that can be expanded over time to include more of the OpenStack
|
||||
universe.
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
*Under development*
|
||||
|
||||
This guide is experimental and currently under development.
|
||||
|
||||
In the meantime you may find this information useful:
|
||||
https://docs.openstack.org/arch-design/use-cases/use-case-general-compute.html
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
The OpenStack Mission Statement: "To produce the ubiquitous Open
|
||||
Source Cloud Computing platform that will meet the needs of public and
|
||||
private clouds regardless of size, by being simple to implement and
|
||||
massively scalable."
|
||||
|
||||
There are many ways one can use OpenStack, but based on the most
|
||||
recent User Survey, 98% of Production and Dev / Test clouds are using
|
||||
Nova [1], the highest of all OpenStack components. Even with a margin
|
||||
of error, we can assume that a Compute cloud is a key feature that's
|
||||
wanted by nearly everyone that enters our community.
|
||||
|
||||
The vision for this constellation is it's a starting place, with functions
|
||||
that nearly all clouds will eventually want to have, and then
|
||||
documented ways to expand the cloud into additional functions. This is about
|
||||
a base minimal set of features to get people familiar with the OpenStack
|
||||
universe.
|
||||
|
||||
Criteria for selecting OpenStack projects as part of this constellation
|
||||
=======================================================================
|
||||
|
||||
* All projects must actively maintain stable branches.
|
||||
|
||||
Rationale: these users will typically deploy stable releases only,
|
||||
and upgrade on stable point releases before jumping to the next
|
||||
stable release.
|
||||
|
||||
* All projects must use the approved base services[2].
|
||||
|
||||
Rationale: providing HA stories for a relational database and AMQP
|
||||
is substantial operational burden. Additional storage or messaging
|
||||
technologies provide too high an operational burden to meet for
|
||||
initial setup.
|
||||
|
||||
* All projects must use oslo.config and oslo.log.
|
||||
|
||||
Rationale: both of these are operator in or out surfaces. All
|
||||
projects in here should have the same mechanisms for input or output
|
||||
from an operational standpoint.
|
||||
|
||||
* All projects must support upgrade without config file change.
|
||||
|
||||
Rationale: the expected upgrade model is code upgrade on existing
|
||||
config files, cleaning up deprecation issues before upgrading to the next.
|
||||
|
||||
* All projects must be a required to put a persistent Virtual Machines on
|
||||
the network.
|
||||
|
||||
Rationale: we'd like to create a small enough starting point that
|
||||
getting everything up and running is a manageable project. We'd like
|
||||
to support persistent virtual machines because it's something most operators
|
||||
are going to immediately have a use for, and can thus try it out for
|
||||
real in their environment.
|
||||
|
||||
* The projects in this constellation should make it easy to add new OpenStack
|
||||
projects into such a deployment over time.
|
||||
|
||||
Rationale: we'd like this to be a solid bit of 'seed corn' from
|
||||
which a larger and richer OpenStack deployment can be built out
|
||||
over time. Starting small with the ability to grow helps OpenStack adoption.
|
||||
|
||||
List of OpenStack projects in this constellation
|
||||
================================================
|
||||
|
||||
Under the current criteria the following projects are part of Compute Starter:
|
||||
|
||||
- keystone
|
||||
- glance
|
||||
- nova
|
||||
- cinder
|
||||
- neutron
|
||||
|
||||
Release Highlights
|
||||
==================
|
||||
|
||||
|
||||
Future Plans
|
||||
============
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
[1] - http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
|
||||
[2] - https://governance.openstack.org/tc/reference/base-services.html
|
|
@ -20,6 +20,7 @@ Repository Information
|
|||
:maxdepth: 1
|
||||
|
||||
contributing
|
||||
constellations/index
|
||||
|
||||
|
||||
Indices and tables
|
||||
|
|
Loading…
Reference in New Issue