Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
This session will include the following subject(s):
Scaling design:
What does scaling mean at the tripleo level; where do we do well, where are lacking, what do we need to design?
(Session proposed by Robert Collins)
Tuskar/TripleO support different architectures:
Justification ------------- Tuskar should support deploying different architectures of TripleO for the undercloud and overcloud.
Supporting a flexible deployment architecture allows Tuskar to deploy OpenStack to meet different goals as needed. In particular, things like:
- different network topologies, such as isolated L2 network domains - different scaling methodologies to support HA
Description ----------- Current example deployments of TripleO use an all in one node for the Undercloud, and an Overcloud with 1 control node and 1 compute node. These are just the example (and well documented deployments). Tuskar should not tie you to any one deployment architecture and instead allow for deploying flexible architectures.
Currently Tuskar assumes that the Undercloud is already deployed, and then uses the Undercloud services to orchestrate a deployment of the Overcloud.
The flexiblity should apply to both the Undercloud and Overcloud.
Proposal(s) ----------- 1. Define a method so that Tuskar can bootstrap the Undercloud. - We could start with a seed vm that Tuskar talks to deploy a simple Undercloud. - Once the Undercloud is up, reconfigure Tuskar to talk to the Undercloud. - Proceed with deploying the Overcloud, or scaling out the Undercloud, etc.
2. Define a mechanism for Tuskar to be able to deploy Undercloud nodes after the seed is removed. - One such mechanism could be using Heat on the Undercloud to deploy additional Undercloud nodes (as opposed to just using the Undercloud heat to deploy the Overcloud). - The Undercloud may need to scale out new baremetal compute nodes as new isolated L2 domains are brought online (new rack for instance). Tuskar should be able to provision these new Undercloud nodes as opposed to a manual setup process. - Other resource type nodes should be able to be added to the Undercloud by Tuskar as well (such as a new network node). - Configuration changes on the Undercloud should be managed by Tuskar. Tuskar should be able to use the heat stack-update API to update the Undercloud (assuming we've used the Undercloud Heat to launch those nodes).
3. Define a method to deploy different heat stacks (could apply to both Undercloud and Overcloud). - Tuskar should have access to a library/repo of different templates for different node types. - A Tuskar admin should be able to select different templates (and a quantity of each) and deploy it as a single stack - A deployed stack should be able to be "stack updated" by adding additional templates (or quantities) and updating the stack from Tuskar.
