openstack
/
charm-heat
Code Issues Proposed changes

Streamline README for policy overrides 

The appendix in the deploy-guide has recently been
refreshed. This is the fourth of the nine charms that
support overrides to receive a streamlining in order
to cut down on duplication.

Some driveby formatting improvements.

Change-Id: I384fba8327222cad8c44a192d35a821c995798c2
This commit is contained in:
Peter Matulis 2020-01-09 12:41:39 -05:00
parent 43d13d91d4
commit 5712e6aece
1 changed files with 49 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
README.md
View File

@ -1,5 +1,4 @@
Overview # Overview
========
Heat is the main project in the OpenStack Orchestration program. It implements Heat is the main project in the OpenStack Orchestration program. It implements
an orchestration engine to launch multiple composite cloud applications based an orchestration engine to launch multiple composite cloud applications based
@ -7,8 +6,7 @@ on templates in the form of text files that can be treated like code.
This charm deploys the Heat infrastructure. This charm deploys the Heat infrastructure.
Usage # Usage
=====
Heat requires the existence of the other core OpenStack services deployed via Heat requires the existence of the other core OpenStack services deployed via
Juju charms, specifically: mysql, rabbitmq-server, keystone and Juju charms, specifically: mysql, rabbitmq-server, keystone and
@ -28,8 +26,7 @@ If using juju 1.x run:
This is only required for >= OpenStack Kilo. This is only required for >= OpenStack Kilo.
HA/Clustering ## HA/Clustering
-------------
There are two mutually exclusive high availability options: using virtual There are two mutually exclusive high availability options: using virtual
IP(s) or DNS. In both cases, a relationship to hacluster is required which IP(s) or DNS. In both cases, a relationship to hacluster is required which
@ -62,21 +59,30 @@ 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 If 'dns-ha' is set and none of the os-{admin,internal,public}-hostname(s) are
set set
Network Space support ## Spaces
---------------------
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. 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. 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. Access to the underlying MySQL instance can also be bound to a specific space
using the shared-db relation.
To use this feature, use the --bind option when deploying the charm: To use this feature, use the --bind option when deploying the charm:
juju deploy heat --bind "public=public-space internal=internal-space admin=admin-space shared-db=internal-space" juju deploy heat --bind \
"public=public-space \
internal=internal-space \
admin=admin-space \
shared-db=internal-space"
alternatively these can also be provided as part of a juju native bundle configuration: Alternatively, these can also be provided as part of a juju native bundle
configuration:
```yaml
heat: heat:
charm: cs:xenial/heat charm: cs:xenial/heat
num_units: 1 num_units: 1
@ -85,51 +91,47 @@ alternatively these can also be provided as part of a juju native bundle configu
admin: admin-space admin: admin-space
internal: internal-space internal: internal-space
shared-db: internal-space shared-db: internal-space
```
NOTE: Spaces must be configured in the underlying provider prior to attempting to use them. NOTE: Spaces must be configured in the underlying provider prior to attempting
to use them.
NOTE: Existing deployments using os-*-network configuration options will continue to function; these options are preferred over any network space binding provided if set. NOTE: Existing deployments using os-*-network configuration options will
continue to function; these options are preferred over any network space
binding provided if set.
Policy Overrides ## Policy Overrides
----------------
This feature allows for policy overrides using the `policy.d` directory. This Policy overrides is an **advanced** feature that allows an operator to override
is an **advanced** feature and the policies that the OpenStack service supports the default policy of an OpenStack service. The policies that the service
should be clearly and unambiguously understood before trying to override, or supports, the defaults it implements in its code, and the defaults that a charm
add to, the default policies that the service uses. The charm also has some may include should all be clearly understood before proceeding.
policy defaults. They should also be understood before being overridden.
> **Caution**: It is possible to break the system (for tenants and other > **Caution**: It is possible to break the system (for tenants and other
services) if policies are incorrectly applied to the service. services) if policies are incorrectly applied to the service.
Policy overrides are YAML files that contain rules that will add to, or Policy statements are placed in a YAML file. This file (or files) is then (ZIP)
override, existing policy rules in the service. The `policy.d` directory is compressed into a single file and used as an application resource. The override
a place to put the YAML override files. This charm owns the is then enabled via a Boolean charm option.
`/etc/heat/policy.d` directory, and as such, any manual changes to it will
be overwritten on charm upgrades.
Overrides are provided to the charm using a Juju resource called
`policyd-override`. The resource is a ZIP file. This file, say
`overrides.zip`, is attached to the charm by:
Here are the essential commands (filenames are arbitrary):
zip overrides.zip override-file.yaml
juju attach-resource heat policyd-override=overrides.zip juju attach-resource heat policyd-override=overrides.zip
The policy override is enabled in the charm using:
juju config heat use-policyd-override=true juju config heat use-policyd-override=true
When `use-policyd-override` is `True` the status line of the charm will be See appendix [Policy Overrides][cdg-appendix-n] in the [OpenStack Charms
prefixed with `PO:` indicating that policies have been overridden. If the Deployment Guide][cdg] for a thorough treatment of this feature.
installation of the policy override YAML files failed for any reason then the
status line will be prefixed with `PO (broken):`. The log file for the charm
will indicate the reason. No policy override files are installed if the `PO
(broken):` is shown. The status line indicates that the overrides are broken,
not that the policy for the service has failed. The policy will be the defaults
for the charm and service.
Policy overrides on one service may affect the functionality of another # Bugs
service. Therefore, it may be necessary to provide policy overrides for
multiple service charms to achieve a consistent set of policies across the Please report bugs on [Launchpad][lp-bugs-charm-heat].
OpenStack system. The charms for the other services that may need overrides
should be checked to ensure that they support overrides before proceeding. For general charm questions refer to the OpenStack [Charm Guide][cg].
<!-- LINKS -->
[cg]: https://docs.openstack.org/charm-guide
[cdg]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide
[cdg-appendix-n]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-policy-overrides.html
[lp-bugs-charm-heat]: https://bugs.launchpad.net/charm-heat/+filebug