Jump to: navigation, search

Difference between revisions of "TripleO/TuskarJunoPlanning"

(Requirements)
(Requirements)
Line 49: Line 49:
  
 
==== Heat ====
 
==== Heat ====
 
  
 
* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
 
* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
Line 68: Line 67:
 
==== Tuskar ====
 
==== Tuskar ====
  
 +
* given a role specification, return the list of Heat parameters that it needs (derived from its image elements) (''may not be required for Juno'')
 +
* given a role specification and its Heat parameters, construct a Heat template that meets those specifications (''may not be required for Juno'')
 +
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
 
* rebuild Tuskar to save and retrieve Heat templates from Swift
 
* rebuild Tuskar to save and retrieve Heat templates from Swift
 
* update CLI as necessary
 
* update CLI as necessary
 +
 +
==== Tuskar-UI ====
 +
 +
* update deployment workflow
  
 
== Auto-Scaling ==
 
== Auto-Scaling ==

Revision as of 10:12, 25 March 2014

Overview

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale (TripleO/TuskarJunoInitialDiscussion). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

  • integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
  • ensuring that Tuskar does not try to implement functionality that is better located in other projects


This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

  • a description of the goal
  • an explanation of the various OpenStack interactions needed
  • a list of project requirements and/or blueprints needed to achieve those interactions

Cloud Service Representation

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

Tuskar Service Model

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

Requirements

Heat

  • Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (may not be required for Juno)

Tuskar

  • ensure existence of default images
  • create default roles, each associated with a list of elements and an image

Tuskar-UI

  • update deployment workflow to accomodate cloud services

Overcloud Planning and Deployment

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

Tuskar Architecture

Requirements

Heat

TripleO

  • update Heat templates in TripleO for: HOT, provider resources, software config
  • given an image element, return the list of Heat parameters that it needs (may not be required for Juno)

Tuskar

  • given a role specification, return the list of Heat parameters that it needs (derived from its image elements) (may not be required for Juno)
  • given a role specification and its Heat parameters, construct a Heat template that meets those specifications (may not be required for Juno)
  • given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
  • rebuild Tuskar to save and retrieve Heat templates from Swift
  • update CLI as necessary

Tuskar-UI

  • update deployment workflow

Auto-Scaling

Requirements

Heat

High Availability

Requirements

TripleO

  • Deploy HA Overcloud
  • glusterfs
  • pacemaker, corosync
  • neutron (?)
  • heat-engine A/A
  • qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
  • etc etc

Tuskar-UI

  • deployment workflow support for HA architecture

Node Management (Ironic)

Requirements

Ironic

  • Ironic graduation
  • CI jobs
  • Nova driver
  • Serial console
  • Migration path
  • User documentation
  • Autodiscovery of nodes
  • Ceilometer
  • Tagging
  • tag nodes for nova scheduler
  • scalability

Heat

  • Ironic resource plugin (may not be required by us)

Metric Graphs

Requirements

Ceilometer

  • Combine samples for different meters in a transformer to produce a single derived meter
  • Rollup of course-grained statistics for UI queries
  • Configurable data retention based on rollups
  • Overarching "health" metric for nodes


To ensure scalability:

  • Eliminate central agent SPoF
  • SNMP batch mode, one bulk command per node per polling cycle


For additional data:

  • Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
  • Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
  • Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

Tuskar-UI

  • Add Ceilometer-based graphs

User Interfaces

Requirements

Horizon

  • separate horizon from openstack-dashboard

Tuskar-CLI

  • create a tuskar-cli plugin for OpenStackClient

Tuskar-UI

  • increase the modularity of views
  • create a mechanism for asynchronous communication