Use Split Stack (deployed-server) by default

Registered by James Slagle on 2016-10-28

Once Split Stack phase 2 is implemented, we should move to a model where we make use of the deployed-server template by default, and always deploy 2 separate stacks during every deployment. We should have a mistral workflow to tie the 2 stacks together so that it is transparent to the operator that we're deploying 2 stacks (it's still just one command to deploy the overcloud).

Blueprint information

Status:
Complete
Approver:
Emilien Macchi
Priority:
Medium
Drafter:
James Slagle
Direction:
Approved
Assignee:
James Slagle
Definition:
Approved
Series goal:
Accepted for pike
Implementation:
Implemented
Milestone target:
milestone icon pike-3
Started by
James Slagle on 2017-04-21
Completed by
James Slagle on 2017-07-24

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/split-stack-default,n,z

Addressed by: https://review.openstack.org/458641
    Add os-collect-config data as an output

Addressed by: https://review.openstack.org/459398
    Add DeploymentSwiftDataMap parameter

Addressed by: https://review.openstack.org/459440
    Add DeploymentSwiftDataMap parameter

Addressed by: https://review.openstack.org/459900
    Add split-stack environments

Addressed by: https://review.openstack.org/460138
    Add VipMap output

Addressed by: https://review.openstack.org/461399
    Add DeployedServerEnvironmentOutput

Addressed by: https://review.openstack.org/461871
    Add documentation for split-stack

Addressed by: https://review.openstack.org/481594
    Use ServerOsCollectConfigData value in output

Addressed by: https://review.openstack.org/490170
    Document using current-tripleo

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.