Fix linting and build errors
Just some errors that seem to have crept in over queens and rocky cycles. Change-Id: I0209239da62fb84ddaffea894956c39a3ec32a2d
This commit is contained in:
Alex Kavanagh
parent
2d93253242
commit
5dcb5d5b3c
|
|
@ -39,7 +39,7 @@ In order to migrate to the new architecture, users will need to:
|
|||
monitor cluster.
|
||||
|
||||
#. Relate the ceph application to the new ceph-mon application. The relation
|
||||
between these two applications is defined in the new `ceph-bootstrap`
|
||||
between these two applications is defined in the new ``ceph-bootstrap``
|
||||
interface, documented herein.
|
||||
|
||||
#. Update the deployments using the ceph-client relation to point to the new
|
||||
|
|
@ -98,10 +98,10 @@ New ceph-bootstrap Interface
|
|||
|
||||
Notably, there exists no way of adding a relation between the ceph-mon charm
|
||||
and the all-in-one ceph charm. To address this, a new interface will be added
|
||||
to the ceph and ceph-mon charms called `ceph-bootstrap`, enabling the
|
||||
necessary information for joining the cluster to be shared. This is
|
||||
essentially the same information that's shared on the peer `mon` interface for
|
||||
the ceph charm itself.
|
||||
to the ceph and ceph-mon charms called ``ceph-bootstrap``, enabling the
|
||||
necessary information for joining the cluster to be shared. This is essentially
|
||||
the same information that's shared on the peer ``mon`` interface for the ceph
|
||||
charm itself.
|
||||
|
||||
Since the charms are not reactive, no new interface repository is required.
|
||||
The information exchanged will contain the following:
|
||||
|
|
@ -133,7 +133,7 @@ charm will fail to join the relation.
|
|||
|
||||
Changes to charm-ceph
|
||||
---------------------
|
||||
In addition to implementing the `ceph-bootstrap` interface, the all-in-one
|
||||
In addition to implementing the ``ceph-bootstrap`` interface, the all-in-one
|
||||
ceph charm needs to properly clean up when removing itself. It should not
|
||||
remove any OSDs or Ceph packages as this would interrupt the operational ceph
|
||||
cluster. However, the charm needs to remove its ceph.conf file as a
|
||||
|
|
@ -162,7 +162,7 @@ Additional assignee(s):
|
|||
Gerrit Topic
|
||||
------------
|
||||
|
||||
Use Gerrit topic `charm-ceph-migration` for all patches related to this spec.
|
||||
Use Gerrit topic ``charm-ceph-migration`` for all patches related to this spec.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ Update neutron-api charm
|
|||
- Update unit tests
|
||||
|
||||
Provide designate interface
|
||||
++++++++++++++++++++++++++
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
- Create new interface to expose public API endpoint of Designate service
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@
|
|||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
===============================
|
||||
=================================
|
||||
Service Restart Control In Charms
|
||||
===============================
|
||||
=================================
|
||||
|
||||
Openstack charms continuously respond to hook events from their peers
|
||||
related applications which frequently result in configuration
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ be recovered without access to the appropriate encryption keys.
|
|||
Proposed Change
|
||||
===============
|
||||
|
||||
Underlying storage devices will be protected using dm-crypt/LUKS with encryption
|
||||
keys stored directly in Hashicorp Vault. No local copy of the key is made during
|
||||
the encryption process or the decryption process on boot.
|
||||
Underlying storage devices will be protected using dm-crypt/LUKS with
|
||||
encryption keys stored directly in Hashicorp Vault. No local copy of the key is
|
||||
made during the encryption process or the decryption process on boot.
|
||||
|
||||
A new tool 'vaultlocker' will be used to LUKS format block devices, directly
|
||||
storing encryption keys in Vault. Keys are referenced using the UUID of the
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@
|
|||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
===============================
|
||||
=================================
|
||||
Extended Swift Cluster Operations
|
||||
===============================
|
||||
=================================
|
||||
|
||||
The Swift charms currently support a subset of operations required to support
|
||||
a Swift cluster over time. This spec proposes expanding on what we already have
|
||||
|
|
|
|||
|
|
@ -178,9 +178,9 @@ Updates to keystone endpoint calculation code
|
|||
Currently the following competing options are used to calculate which EP should
|
||||
be registered in Keystone:
|
||||
|
||||
* os-*-network set do resolve_address old method
|
||||
* os-\*-network set do resolve_address old method
|
||||
* dnsha use dnsha
|
||||
* os-*-hostname set use hostname
|
||||
* os-\*-hostname set use hostname
|
||||
* juju network space binding via extra-bindings
|
||||
* prefer ipv6 via configuration option
|
||||
* presence of {public,internal,admin}-backend relations to
|
||||
|
|
|
|||
Loading…
Reference in New Issue