Single process Heat driven Undercloud installer
Change-Id: I8ad6772233294d0fd802ee6d5dbe133c77472a02
This commit is contained in:
Dan Prince
Emilien Macchi
parent
3cca23ac90
commit
79398c9ace
|
|
@ -0,0 +1,177 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
================================
|
||||
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
|
||||
==========
|
||||
|
||||
* Onward dark owl presentation: https://www.youtube.com/watch?v=y1qMDLAf26Q
|
||||
|
||||
* https://etherpad.openstack.org/p/tripleo-composable-undercloud
|
||||
|
||||
* https://blueprints.launchpad.net/tripleo/+spec/heat-undercloud
|
||||
Loading…
Reference in New Issue