Jump to: navigation, search

TripleO/TuskarJunoInitialDiscussion

< TripleO
Revision as of 18:58, 6 March 2014 by Tzumainn (talk | contribs) (=Cloud Planning)

Overview

This information is based on discussions from the TripleO mid-cycle Icehouse meetup in San Francisco.

One concept independently stressed by many people is: Tuskar should take advantage of existing OpenStack services. Although we have made strides in following this philosophy in the Icehouse development cycle, several discussions described how we might go further down this path. If we were to follow those suggestions, consequences would be felt both in current architecture and future feature planning.

Re-Architecture

Cloud Planning

In Icehouse, user-configurable cloud planning is represented by the state that is kept in Tuskar API: the roles, the role counts, the stack parameters, etc. At deploy-time, this information is passed down and used to construct a Heat template which is then used to create a stack that is deployed by Heat. The template does not exist separately from the deployed stack.

However, if we take a step back, the intent of a Heat template is: a plan. If we can simply use a Heat template for cloud planning, we eliminate the need for a stateful Tuskar API. The problem is that Heat itself does not separate out the plan (template) from the deployment (stack). However, there is no reason why we cannot create a template to capture the plan and then store it elsewhere.

Using Swift for template storage solves this problem. At a high level, this would work as follows:

  • during planning stages, the template is written and updated in Swift
  • when a user deploys a cloud, the template is read from Swift and directly used to create the Heat stack.


Additional notes:

  • Swift will store the Heat template and deployment "answers" (parameters, config options)
  • Swift object IDs stored in template metadata
  • Parser needed to break apart and write template and answers (Tuskar service)
  • Removes need for stateful Tuskar API
  • Swift has built-in versioning (future consideration)

Here is a diagram that details Tuskar's proposed interactions with OpenStack services: Jay's Picture

Feature Improvement

  • Service
  • Role

Develop what we can based on what exists; don't over-design within Tuskar.

User Workflow