composable-undercloud

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/tripleo/+spec/heat-undercloud

Deploy the undercloud with Heat instead of elements. This will allow us to use composable services for the Undercloud and better fits with the architecture of TripleO (providing a feedback loop between the Undercloud and Overcloud). Furthermore this gets us a step closer to an HA undercloud and will help us potentially convert the Undercloud to containers as work is ongoing in t-h-t for containers as well.

Problem Description

The Undercloud today uses instack-undercloud. Instack undercloud is built around the concept of ‘instack’ which uses elements to install service.

  • When instack-undercloud started we shared elements across the undercloud and overcloud via the tripleo-image-elements project. This is no longer the case, thus we have lost the feedback loop of using the same elements in both the overcloud and undercloud.

  • We retro-fitted instack-undercloud with a single element called puppet-stack-config that contains a single (large) puppet manifest for all the services. Being able to compose the Undercloud would be more scalable.

  • A maintenance problem. Ideally we could support the under and overcloud with the same tooling.

Proposed Change

Overview

We can use a single process Heat API/Engine in noauth mode to leverage recent “composable services” work in the tripleo-heat-templates project.

  • A new heat-all launcher will be created.

  • We will run the heat-all launcher with “noauth” middleware to skip keystone auth at a high level.

  • The heat-all process will use fake RPC driver and SQLite thus avoiding the need to run RabbitMQ or MySQL on the deployment server for bootstrapping.

  • To satisfy client library requirements inside heat we will run a fake keystone API (a thread in our installer perhaps), that will return just enough to make these clients functionally work in noauth mode.

  • The new “deployed-server” feature in tripleo-heat-templates will make it it possible to create Heat “server” objects and thus run OS::Heat::SoftwareDeployment resources on pre-installed servers.

  • We will use os-collect-config to communicate with the local Heat API via the Heat signal transport. We will run os-collect-config until the stack finished processing and either completes or fails.

Alternatives

  • Create another tool which can read composable services in tripleo-heat-templates. This tool would be required to have feature parity with Heat such that things like parameters, nested stacks, environments all worked in a similar fashion so that we could share the template work across the Undercloud and Overcloud. This approach isn’t really feasable.

  • Use an alternate tool like Ansible. This would creating duplicate services in Ansible playbooks for each service we require in the Undercloud. This approach isn’t ideal in that it involves duplicate work across the Undercloud and Overcloud. Ongoing work around multi-node configuration and containers would need to be duplicated into both the Overcloud (tripleo-heat-templates) and Undercloud (Ansible) frameworks.

Security Impact

  • The approach would run Heat on a single node in noauth mode. Heat API and the fake Keystone stub would listen on 127.0.0.1 only. This would be similar to other projects which allow noauth in local mode as well.

Other End User Impact

  • We would again have a single template language driving our Undercloud and Overcloud tooling. Heat templates are very well documented.

Performance Impact

  • Initial testing shows the single process Heat API/Engine is quite light taking only 70MB of RAM on a machine.

  • The approach is likely to be on-par with the performance of instack-undercloud.

Other Deployer Impact

  • The format of undercloud.conf may change. We will add a ‘compat’ layer which takes the format of ‘undercloud.conf’ today and sets Heat parameters and or includes heat environments to give feature parity and an upgrade path for existing users. Additional, CI jobs will also be created to ensure users who upgrade from previous instack environments can use the new tool.

Developer Impact

  • Developers would be able to do less work to maintain the UnderCloud by sharing composable services.

  • Future work around composable upgrades could also be utilized and shared across the Undercloud and Overcloud.

Implementation

Assignee(s)

dprince (dan-prince on LP)

Work Items

  • Create heat-all launcher.

  • Create python-tripleoclient command to run ‘undercloud deploy’.

  • Create undercloud.yaml Heat templates.

Dependencies

  • Heat all launcher and noauth middleware.

Testing

Swapping in the new Undercloud as part of CI should allow us to fully test it.

Additionally, we will have an upgrade job that tests an upgrade from an instack-undercloud installation to a new t-h-t driven Undercloud install.

Documentation Impact

Documentation changes will need to be made that explains new config interfaces (Heat parameters and environments). We could minimiz doc changes by developing a ‘compat’ interface to process the legacy undercloud.conf and perhaps even re-use the ‘undercloud install’ task in python-tripleoclient as well so it essentially acts the same on the CLI.

References