Jump to: navigation, search

Difference between revisions of "TripleO/TuskarJunoPlanning"

(Ceilometer)
(Ceilometer)
Line 119: Line 119:
 
* Eliminate central agent SPoF
 
* Eliminate central agent SPoF
 
* SNMP batch mode, one bulk command per node per polling cycle
 
* SNMP batch mode, one bulk command per node per polling cycle
 +
* Use Keystone v3 for auth on autoscale instead of presigned URL
 +
* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)
  
 
==== Heat ====
 
==== Heat ====

Revision as of 15: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
  • a list of project requirements and/or blueprints needed

Cloud Service Representation

Description

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

Description

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

High Availability

Description

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

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

  • allow the generation of Heat templates that support HA

Tuskar-UI

  • deployment workflow support for HA architecture

Auto-Scaling

Description

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

Requirements

Ceilometer

  • Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
  • Eliminate central agent SPoF
  • SNMP batch mode, one bulk command per node per polling cycle
  • Use Keystone v3 for auth on autoscale instead of presigned URL
  • Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

Heat

  • hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
  • choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
  • support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (may not be required for Juno)
  • Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

TripleO

  • update image elements to support auto-scaling

Tuskar

  • allow the generation of Heat templates that support auto-scaling

Tuskar-UI

  • update deployment workflow to include options that allow an auto-scaled overcloud deployment

Node Management (Ironic)

Description

Requirements

Ironic

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

Nova

  • ensure that flavor metadata can include node tag values
  • create a nova filter for exact matches to Ironic nodes (including all node metadata)

Heat

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

Metric Graphs

Description

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


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

Description

Requirements

Horizon

  • separate horizon from openstack-dashboard
  • test the replacement of lesscpy with pyScss

Tuskar-CLI

  • create a tuskar-cli plugin for OpenStackClient

Tuskar-UI

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