heat
#0

Description

Heat is the main project in the OpenStack Orchestration program. It implements an
orchestration engine to launch multiple composite cloud applications based on
templates in the form of text files that can be treated like code.

Overview

Heat is the main project in the OpenStack Orchestration program. It implements
an orchestration engine to launch multiple composite cloud applications based
on templates in the form of text files that can be treated like code.

This charm deploys the Heat infrastructure.

Usage

Heat requires the existence of the other core OpenStack services deployed via
Juju charms, specifically: mysql, rabbitmq-server, keystone and
nova-cloud-controller. The following assumes these services have already
been deployed.

After deployment of the cloud, the domain-setup action must be run to configure
required domains, roles and users in the cloud for Heat stacks.

For juju 2.x deployments use:

juju run-action heat/0 domain-setup

If using juju 1.x run:

juju action do heat/0 domain-setup

This is only required for >= OpenStack Kilo.

HA/Clustering

There are two mutually exclusive high availability options: using virtual
IP(s) or DNS. In both cases, a relationship to hacluster is required which
provides the corosync back end HA functionality.

To use virtual IP(s) the clustered nodes must be on the same subnet such that
the VIP is a valid IP on the subnet for one of the node's interfaces and each
node has an interface in said subnet. The VIP becomes a highly-available API
endpoint.

At a minimum, the config option 'vip' must be set in order to use virtual IP
HA. If multiple networks are being used, a VIP should be provided for each
network, separated by spaces. Optionally, vip_iface or vip_cidr may be
specified.

To use DNS high availability there are several prerequisites. However, DNS HA
does not require the clustered nodes to be on the same subnet.
Currently the DNS HA feature is only available for MAAS 2.0 or greater
environments. MAAS 2.0 requires Juju 2.0 or greater. The clustered nodes must
have static or "reserved" IP addresses registered in MAAS. The DNS hostname(s)
must be pre-registered in MAAS before use with DNS HA.

At a minimum, the config option 'dns-ha' must be set to true and at least one
of 'os-public-hostname', 'os-internal-hostname' or 'os-internal-hostname' must
be set in order to use DNS HA. One or more of the above hostnames may be set.

The charm will throw an exception in the following circumstances:
If neither 'vip' nor 'dns-ha' is set and the charm is related to hacluster
If both 'vip' and 'dns-ha' are set as they are mutually exclusive
If 'dns-ha' is set and none of the os-{admin,internal,public}-hostname(s) are
set

Network Space support

This charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju. This is only supported with Juju 2.0 and above.

API endpoints can be bound to distinct network spaces supporting the network separation of public, internal and admin endpoints.

Access to the underlying MySQL instance can also be bound to a specific space using the shared-db relation.

Configuration

(boolean)
If True enables openstack upgrades for this charm via juju actions.
You will still need to set openstack-origin to the new repository but
instead of an upgrade running automatically across all units, it will
wait for you to execute the openstack-upgrade action for this charm on
each unit. If False it will revert to existing behavior of upgrading
all units on config change.

(string)
The default user for new instances. This option is deprecated as of Juno.
If left empty, Heat will use the default user set up with your cloud
image (for OS::Nova::Server) or 'ec2-user' (for AWS::EC2::Instance).

(string)
Repository from which to install. May be one of the following:
distro (default), ppa:somecustom/ppa, a deb url sources entry,
or a supported Ubuntu Cloud Archive e.g.
.
cloud:<series>-<openstack-release>
cloud:<series>-<openstack-release>/updates
cloud:<series>-<openstack-release>/staging
cloud:<series>-<openstack-release>/proposed
.
See https://wiki.ubuntu.com/OpenStack/CloudArchive for info on which
cloud archives are available and supported.
.
NOTE: updating this setting to a source that is known to provide
a later version of OpenStack will trigger a software upgrade unless
action-managed-upgrade is set to True.

(string)
The hostname or address of the admin endpoints created for heat
in the keystone identity provider.
.
This value will be used for admin endpoints. For example, an
os-admin-hostname set to 'heat.admin.example.com' with ssl enabled will
create the following admin endpoints for ceilometer:
.
https://heat.admin.example.com:8004/

(string)
The hostname or address of the internal endpoints created for heat
in the keystone identity provider.
.
This value will be used for internal endpoints. For example, an
os-internal-hostname set to 'heat.internal.example.com' with ssl enabled
will create the following internal endpoints for ceilometer:
.
https://heat.internal.example.com:8004/

(string)
The hostname or address of the public endpoints created for heat
in the keystone identity provider.
.
This value will be used for public endpoints. For example, an
os-public-hostname set to 'heat.example.com' with ssl enabled will
create the following public endpoints for ceilometer:
.
https://heat.example.com:8004/

(boolean)
If True enables IPv6 support. The charm will expect network interfaces
to be configured with an IPv6 address. If set to False (default) IPv4
is expected.
.
NOTE: these charms do not currently support IPv6 privacy extension. In
order for this charm to function correctly, the privacy extension must be
disabled and a non-temporary address must be configured/available on
your network interface.

(string)
SSL certificate to install and use for API ports. Setting this value
and ssl_key will enable reverse proxying, point Heat's entry in the
Keystone catalog to use https, and override any certificate and key
issued by Keystone (if it is configured to do so).

(float)
The CPU core multiplier to use when configuring worker processes for
this service. By default, the number of workers for each daemon is
set to twice the number of CPU cores a service unit has. When deployed
in a LXD container, this default value will be capped to 4 workers
unless this configuration option is set.

Relations
Relations enable services to easily and securely share information with each other.