This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
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.
View analytic
Tuesday, November 5 • 11:15am - 11:55am
Deployment scaling/topologies

Sign up or log in to save this to your schedule and see who's attending!

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:

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

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

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.

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

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.

(Session proposed by James Slagle)

Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 203

Attendees (79)