Jump to: navigation, search

Difference between revisions of "TripleO/TuskarIcehouseRequirements"

(Overcloud Roles)
(Image)
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
  
For Icehouse, we will create an UI to allow users to deploy an Overcloud.  This
+
For Icehouse, we will create an UI to allow users to deploy an overcloud.  This
 
UI will build upon the Horizon framework, but be functional without the existing OpenStack
 
UI will build upon the Horizon framework, but be functional without the existing OpenStack
 
Dashboard tabs (Project, Admin).  This separation is to reduce user confusion, as much
 
Dashboard tabs (Project, Admin).  This separation is to reduce user confusion, as much
of the functionality in those tabs simply do not apply.
+
of the functionality in those tabs simply do not apply to overcloud deployment.
  
 
== Nodes ==
 
== Nodes ==
Line 12: Line 12:
 
whether a Nova instance is deployed upon that node).
 
whether a Nova instance is deployed upon that node).
  
The UI will allow free nodes to be unregistered.
+
The UI will not allow nodes to be unregistered for historical purposes.
  
 
== Overcloud Roles ==
 
== Overcloud Roles ==
Line 22: Line 22:
 
* object storage
 
* object storage
 
* block storage
 
* block storage
 +
  
 
These roles are created when Tuskar is installed.  Roles cannot be created or removed.
 
These roles are created when Tuskar is installed.  Roles cannot be created or removed.
  
Each role is associated with an image name and a single flavor.  This image name cannot
+
=== Image ===
be modified; however, the flavor association can be.
 
  
== Flavors ==
+
A role is associated with an image name; the overcloud Heat template will expect an image with
 +
that name to exist.  These images are '''not''' managed through the Tuskar UI; instead, Users are expected to have the appropriate images in Glance.
  
Tuskar provides its own interface for CRUD operations on flavors.
+
The image name cannot be modified through the Tuskar UI, as it must match the image name in the Heat template.
  
== Images ==
+
=== Flavor ===
  
Users are expected to create images for specifc roles through CLI.
+
A role is associated with a single Nova flavor.  When deploying an Overcloud, the Nova scheduler
 +
uses exact matching with this flavor to determine which nodes to use.  This means that the nodes
 +
deployed for a given role must be homogeneous.
 +
 
 +
The Tuskar UI provides its own interface for CRUD operations on flavors.
  
 
== Overcloud Deployment ==
 
== Overcloud Deployment ==
  
Only a single deployment allowed.
+
Only a single overcloud is allowed.  Before deploying an overcloud, a user must specify:
 
 
==== Planning ====
 
 
 
* nodes per role
 
* deployment configuration
 
 
 
==== Deploying ====
 
 
 
* Heat template generated on the fly
 
* nova scheduler allocates nodes, uses exact flavor matching
 
* status indicator to determine overall state of deployment
 
* Deployment action can create or update
 
* Can scale upwards, but not downwards
 
 
 
==== Maintenance ====
 
 
 
* Logs
 
* View nodes by role
 
 
 
== Post-Icehouse Requirements ==
 
  
heterogeneous nodes
+
* the number of nodes per role
 +
* various deployment configuration parameters
  
During deployment
 
** status indicator for nodes as well
 
** ''status includes 'time left' (**)''
 
  
** ''allow multiple deployments (**)''
+
Once done, the user can trigger the creation of the overcloud.  Creation is done by
 +
using the deployment specifications to generate an overcloud Heat template that is
 +
then used to create an overcloud Heat stack.  During this process, users will see a
 +
status indicator in the UI that monitors the overall state of the deployment.
  
** ''hardware specs from Ironic based on IPMI address and MAC address (*)''
+
Post-deployment, the overcloud can be scaled upwards by increasing the number of
** ''IPMI address auto populated from Neutron (**)''
+
nodes in a role.  The overcloud cannot be scaled downwards, nor can the deployment
* ''Node auto-discovery(*)''
+
configuration parameters be modified.
  
==== Management node ====
+
Once an overcloud is deployed, users can also view information about the Nova servers
* where undercloud is installed
+
deployed for that stack, classified by role.  Users can also view a log corresponding to the
* created as part of undercloud install process
+
Heat events relevant to the overcloud stack.
** ''allow creation of additional management nodes through UI (**)''
 
  
==== Monitoring ====
+
== Next Steps ==
* Service monitoring
 
** assignment, availability, status
 
** ''capacity, historical statistics (*)''
 
* Node monitoring
 
** assignment, availability, status
 
** ''capacity, historical statistics (*)''
 
  
* ''Networks (**)''
+
Here are a list of items we would like to address once the above is complete:
* ''Images (**)''
 
* ''Logs (**)''
 
* ''Archived nodes (**)''
 
* ''Manual node allocation (**)''
 
  
==== Other ====
+
* multiple flavors per role ("heterogeneous nodes")
* ''review distribution map (**)''
+
* auto-discovery of nodes through Ironic
* notification when a deployment is ready to go or whenever something changes
+
* image management
 +
* monitoring capabilities
 +
* user notifications

Latest revision as of 14:24, 5 February 2014

Overview

For Icehouse, we will create an UI to allow users to deploy an overcloud. This UI will build upon the Horizon framework, but be functional without the existing OpenStack Dashboard tabs (Project, Admin). This separation is to reduce user confusion, as much of the functionality in those tabs simply do not apply to overcloud deployment.

Nodes

The UI allows users to manually register nodes with Ironic. Once done, the UI maintains a listing of nodes, classified as either 'Free' or 'Deployed' (depending on whether a Nova instance is deployed upon that node).

The UI will not allow nodes to be unregistered for historical purposes.

Overcloud Roles

Tuskar recognizes four roles for nodes, ultimately used within the overcloud Heat template.

  • compute
  • controller
  • object storage
  • block storage


These roles are created when Tuskar is installed. Roles cannot be created or removed.

Image

A role is associated with an image name; the overcloud Heat template will expect an image with that name to exist. These images are not managed through the Tuskar UI; instead, Users are expected to have the appropriate images in Glance.

The image name cannot be modified through the Tuskar UI, as it must match the image name in the Heat template.

Flavor

A role is associated with a single Nova flavor. When deploying an Overcloud, the Nova scheduler uses exact matching with this flavor to determine which nodes to use. This means that the nodes deployed for a given role must be homogeneous.

The Tuskar UI provides its own interface for CRUD operations on flavors.

Overcloud Deployment

Only a single overcloud is allowed. Before deploying an overcloud, a user must specify:

  • the number of nodes per role
  • various deployment configuration parameters


Once done, the user can trigger the creation of the overcloud. Creation is done by using the deployment specifications to generate an overcloud Heat template that is then used to create an overcloud Heat stack. During this process, users will see a status indicator in the UI that monitors the overall state of the deployment.

Post-deployment, the overcloud can be scaled upwards by increasing the number of nodes in a role. The overcloud cannot be scaled downwards, nor can the deployment configuration parameters be modified.

Once an overcloud is deployed, users can also view information about the Nova servers deployed for that stack, classified by role. Users can also view a log corresponding to the Heat events relevant to the overcloud stack.

Next Steps

Here are a list of items we would like to address once the above is complete:

  • multiple flavors per role ("heterogeneous nodes")
  • auto-discovery of nodes through Ironic
  • image management
  • monitoring capabilities
  • user notifications