Jump to: navigation, search

Difference between revisions of "TripleO/TuskarJunoInitialDiscussion"

(Cloud Planning and Swift)
(Cloud Planning and Swift)
Line 30: Line 30:
 
Here is a diagram that details Tuskar's proposed interactions with OpenStack services:
 
Here is a diagram that details Tuskar's proposed interactions with OpenStack services:
  
[[File:http://jdob.fedorapeople.org/tuskar-arch.png|Tuskar Interactions]]
+
[[File:tuskar-arch-juno.png|Tuskar Architecture]]
  
 
== Feature Improvements ==
 
== Feature Improvements ==

Revision as of 19:32, 6 March 2014

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 and Swift

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:

Tuskar Architecture

Feature Improvements

Services

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

With the service concept in play, roles are updated as follows: instead of being associated with images, they are associated with a list of service elements. The user can then either supply the appropriate image for those elements; or use diskimage-builder to create a custom image.

This provides great 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 and scale it separately.

Tuskar can still provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role.

Other

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

User Workflow