Helm charts for deploying OpenStack on Kubernetes
d78f8e0901
* Changed podManagementPolicy to parallel in order to allow recovery from secondary or third master After rebooting the whole cluster on purpose or after a power failure a primary node the cluster can synchronize with is required. This is usually done automatically by selecting the node with the highest transaction id. The current implementation of the stateful set starts the nodes in sequence, preventing the start of further nodes if the process terminates with error state. Because of this, the cluster may not come up if the first or second node are not in primary state. * Elects first node started in primary state as bootstrap source. * Display warnings and runs mysqld with wsrep-recover on crashed nodes * Introduces FORCE_RECOVERY argument for crash recovery In case the primary selection failed, the cluster bootstrap process must be manually initiated from the most advanced node (highest committed transaction id). This information is available from the grastate.dat file in case of a clean shutdown. On crashed nodes an InnoDB recovery is required to get the last committed transaction id. start.sh will handle both cases and gives instructions on how to recover the cluster on a hard failure. If FORCE_RECOVERY was set to the name of a POD (mariadb-0, mariadb-1, ...), the bootstrap process will be initiated from the specified node. DocImpact Closes-Bug: #1716461 Change-Id: I96a8cb52124f64920a7d9cf21a8924ede78ebf7b |
||
---|---|---|
barbican | ||
ceilometer | ||
ceph | ||
cinder | ||
congress | ||
doc | ||
etcd | ||
glance | ||
gnocchi | ||
heat | ||
helm-toolkit | ||
horizon | ||
ingress | ||
ironic | ||
keystone | ||
ldap | ||
libvirt | ||
magnum | ||
mariadb | ||
memcached | ||
mistral | ||
mongodb | ||
neutron | ||
nova | ||
openvswitch | ||
postgresql | ||
rabbitmq | ||
rally | ||
senlin | ||
tests | ||
tools | ||
.gitignore | ||
.gitreview | ||
.zuul.yaml | ||
CONTRIBUTING.rst | ||
LICENSE | ||
Makefile | ||
README.rst | ||
setup.cfg | ||
setup.py | ||
tox.ini |
OpenStack-Helm
Mission
The goal of OpenStack-Helm is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes.
Communication
- Join us on Slack - #openstack-helm
- Join us on IRC: #openstack-helm on freenode
- Community IRC Meetings: [Every Tuesday @ 3PM UTC], #openstack-meeting-5 on freenode
- Meeting Agenda Items: Agenda
Launchpad
Bugs and blueprints are tracked via OpenStack-Helm's Launchpad.
Installation and Development
Please review our documentation. For quick installation, evaluation, and convenience, we have a kubeadm based all-in-one solution that runs in a Docker container. The Kubeadm-AIO set up can be found here.
This project is under active development. We encourage anyone interested in OpenStack-Helm to review our Installation documentation. Feel free to ask questions or check out our current Issues and Bugs.
To evaluate a multinode installation, follow the Bare Metal install guide.