Include the URL of your launchpad blueprint:
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.
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
- A maintenance problem. Ideally we could support the under and overcloud with the same tooling.
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.
- 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
- 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.
- 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
Other End User Impact
- We would again have a single template language driving our Undercloud
and Overcloud tooling. Heat templates are very well documented.
- 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
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.
- 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.
dprince (dan-prince on LP)
- Create heat-all launcher.
- Create python-tripleoclient command to run ‘undercloud deploy’.
- Create undercloud.yaml Heat templates.
- Heat all launcher and noauth middleware.
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 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.