Difference between revisions of "TripleO/TuskarJunoPlanning"
< TripleO
(→Ironic) |
(→Metric Graphs) |
||
| Line 24: | Line 24: | ||
== Metric Graphs == | == Metric Graphs == | ||
| + | |||
| + | === Requirements === | ||
| + | |||
| + | ==== Ceilomenter ==== | ||
| + | |||
| + | * 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 | ||
== Horizon == | == Horizon == | ||
Revision as of 08:19, 24 March 2014
Contents
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
Overcloud Stack Management
Cloud Service Representation
Advanced Cloud Deployment
Ironic Usage
Metric Graphs
Requirements
Ceilomenter
- 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
