Ceph has a function to collect health metrics through smartctl or nvme
command out of the box. And it relies on sudo spawned from the ceph-osd
process so it needs to be considered in the apparmor policy.
[/etc/sudoers.d/ceph-smartctl in ceph-base package]
> ## allow ceph daemons (which run as user ceph) to collect device
> ## health metrics
>
> ceph ALL=NOPASSWD: /usr/sbin/smartctl -x --json=o /dev/*
> ceph ALL=NOPASSWD: /usr/sbin/nvme * smart-log-add --json /dev/*
Also sync charmhelpers and mock platform info
Closes-Bug: #2031637
Change-Id: I981a5db0fd49eca83aa8a619f0cbd0d34a533842
* charm-helpers sync for classic charms
* build.lock file for reactive charms
* ensure tox.ini is from release-tools
* ensure requirements.txt files are from release-tools
* On reactive charms:
- ensure stable/21.04 branch for charms.openstack
- ensure stable/21.04 branch for charm-helpers
Change-Id: I773d5f9f699af1a2ea7be543c4e58e0f7bc4433a
The network-get --primary-address juju-info fails on pre-2.8.?
versions of juju. This results in a NoNetworkBinding error.
Fallback to unit_get() if that occurs for local_address().
Change-Id: I3a7d4e5093f15a1fb32310522229d0b4ebd61c59
Includes updates to charmhelpers/charms.openstack for cert_utils
and unit-get for the install hook error on Juju 2.9
* charm-helpers sync for classic charms
* rebuild for reactive charms
* ensure tox.ini is from release-tools
* ensure requirements.txt files are from release-tools
* On reactive charms:
- ensure master branch for charms.openstack
- ensure master branch for charm-helpers
Change-Id: Ie6146da90c4adc38e817e644e1328ad6c41d678f
* charm-helpers sync for classic charms
* rebuild for reactive charms
* ensure tox.ini is from release-tools
* ensure requirements.txt files are from release-tools
* On reactive charms:
- ensure master branch for charms.openstack
- ensure master branch for charm-helpers
Change-Id: Iffb92ef062f307bc9b2b27e217431b2fc122acfc
Sync in updates from charm-helpers and charms.ceph.
Depends-On: I153c22efb952fc38c5e3d36eed5d85c953e695f7
Depends-On: Ibec4e3221387199adbc1a920e130975d7b25343c
Change-Id: I028440002cdd36be13aaee4a0f50c6a0bca7abda
- Adds groovy to the series in the metadata
- Classic charms: sync charm-helpers.
- Classic ceph based charms: also sync charms.ceph
- Reactive charms: trigger a rebuild
Change-Id: I56a59d0c4e72a35b7c4ac5d989e0d005fae20946
Apply OSD settings requested by the mons via the juju relation.
Add the OSD settings to config too. Before applying the settings
config-flags is checked to ensure there is no overlap.
Change-Id: Id69222217a1c99d0269831913abdf488791cb572
The referenced bug is essentially: make vault:secrets relation to vault
but keep the 'encrypt' option as False. In this case, the Context
handling code in charm-helpers is expecting python3-hvac to be
available, but it is only installed if the encrypt option is set to
True. Hence the charm crashes. This resolves that crash.
Note the related charm-helpers fix [1].
[1]: https://github.com/juju/charm-helpers/pull/431
Change-Id: I9cb60a9340554c91668272b46f7c2dcf9f0ac2d1
Closes-bug: #1862085
Also gate checking vault context completing on whether
dependencies are installed.
Change-Id: I6c89944960f592300921fbd455c6d1d8c4b9b2a2
Closes-Bug: #1849323
Using the new version of the sync tool which removes the charmhelpers
directory before syncing, run charm helpers sync to find any unexpected
missing dependencies.
Change-Id: I88706824d0f755b016fc393b273a76e9b09aa4c3
Resync with latest updates to charms.ceph to avoid explicit
installation of python-ceph which is not required and breaks
under the laters Ceph packaging which no longer ships Python 2
support.
Change-Id: I4ce2b91dd476f90c30d1379dac5b00b8aaa9c73a
Do not reformat devices. A subsequent change will be necessary
to account for conditions where a reformat is still desired,
such as a set of blocking states and user-driven actions.
Partial-bug: #1698154
Depends-On: I90a866aa138d18e4242783c42d4c7c587f696d7d
Change-Id: I3a41ab38e7a1679cf4f5380a7cc56556da3aaf2b
vaultlocker provides support for storage of encryption keys
for LUKS based dm-crypt device in Hashicorp Vault.
Add support for this key management approach for Ceph
Luminous or later. Applications will block until vault
has been initialized and unsealed at which point OSD devices
will be prepared and booted into the Ceph cluster.
The dm-crypt layer is placed between the block device
parition and the top level LVM PV used to create VG's
and LV's to support OSD operation.
Vaultlocker enables a systemd unit for each encrypted
block device to perform unlocking during reboots of the
unit; ceph-volume will then detect the new VG/LV's and
boot the ceph-osd processes as required.
Note that vault/vaultlocker usage is only supported with
ceph-volume, which was introduced into the Ubuntu packages
as of the 12.2.4 point release for Luminous. If vault is
configured as the key manager in deployments using older
versions, a hook error will be thrown with a blocked
status message to this effect.
Change-Id: I713492d1fd8d371439e96f9eae824b4fe7260e47
Depends-On: If73e7bd518a7bc60c2db08e2aa3a93dcfe79c0dd
Depends-On: https://github.com/juju/charm-helpers/pull/159
Switch to using ceph-volume + LVM for managing block devices
for Luminous and later; this is the upstream preferred approach
to managing OSD devices, allowing for more flexibility in terms
of use of crypto and logical volumes.
Change-Id: I30c4d29e6f568ac2e30a45b1a7bc0e68685c3707
Depends-On: I1675b67d364ae6042129a8a717d4bdffff5bde92
Utkarsh Bhatt