918da6d055
The divingbell pods use a hostPath volume for the root filesystem. Because this mount includes /var/lib/kubelet, the pod holds a reference to every volume mounted by every pod on the same host. The most visible case where this causes a problem is the termination of a pod that uses a ceph-backed PVCs. When kubelet tries to unmap the rbd device, it is unable to do so, manifesting in the kubelet logs as: rbd: unmap failed: (16) Device or resource busy This change sets the mountPropagation to HostToContainer for the rootfs volume, so that the divingbell pods will not prevent kubelet from releasing these devices. https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation Change-Id: I6e91fb9b9d7cbe852c5e6dc8b7224d6085175590 |
||
---|---|---|
.github | ||
divingbell | ||
doc | ||
tools | ||
.gitignore | ||
.gitreview | ||
.zuul.yaml | ||
LICENSE | ||
Makefile | ||
README.rst | ||
TODO | ||
Vagrantfile | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
Divingbell
Introduction
Divingbell is a lightweight solution for:
1. Bare metal configuration management for a few very targeted use cases via the following modules:
- apparmor
- ethtool
- exec (run arbitrary scripts)
- system limits
- mounts
- permissions (perm)
- sysctl values
- basic user account management (uamlite)
- Bare metal package manager orchestration using apt module
What problems does it solve?
The needs identified for Divingbell were:
- To plug gaps in day 1 tools (e.g., Drydock) for node configuration
- To provide a day 2 solution for managing these configurations going forward
- [Future] To provide a day 2 solution for system level host patching
Documentation
Find more documentation for Divingbell on Read the Docs.