Examples and references to use Chef for OpenStack projects
Ruby Shell
Permalink
Failed to load latest commit information.
.chef Convert provisioning recipes to cookbook Jun 28, 2016
data_bags Add heat_domain_admin user password to data_bags Oct 12, 2017
doc Documentation updates for Ocata Aug 14, 2017
environments Disabled epel repo, cleaned up environments files Jan 28, 2018
playbooks Bumped ChefDK release to 2.3.4 Jan 30, 2018
roles Cleaned up minimal role, deprecated provisioning cookbook Feb 9, 2018
test/tempest/default Revert inspec test to use Tempest from git Feb 9, 2018
tools Initial repo Pike updates Sep 27, 2017
.gitignore Update repo with new testing suite Feb 26, 2015
.gitreview Update .gitreview file for project rename Jun 12, 2015
.kitchen.dokken.yml Pin test kitchen to chef 13.6.4 Feb 8, 2018
.kitchen.multi.yml Pin test kitchen to chef 13.6.4 Feb 8, 2018
.kitchen.yml Pin test kitchen to chef 13.6.4 Feb 8, 2018
.rubocop.yml Refactored provisioning cookbook for Ocata, ChefDK updates Aug 2, 2017
.rubocop_todo.yml Updated integration attributes and methods Dec 24, 2017
.zuul.yaml Zuul: Remove project name Feb 1, 2018
Berksfile Updated integration attributes and methods Dec 24, 2017
CONTRIBUTING.md Updated the contrib docs Nov 1, 2017
LICENSE Apache License v2.0 Oct 12, 2012
README.md Documentation updates for Ocata Aug 14, 2017
Rakefile Updated integration attributes and methods Dec 24, 2017
TESTING.md Removed Spiceweasel Jul 6, 2015
bindep.txt Implement native zuul v3 tests Oct 27, 2017
bootstrap.sh fix recipe order for allinone role and bootstrap.sh Mar 7, 2016

README.md

Team and repository tags

Team and repository tags

Chef OpenStack Logo

Testing framework for deploying OpenStack using Chef

This is the testing framework for OpenStack deployed using Chef. We leverage this to test against our changes to our cookbooks to make sure that you can still build a cluster from the ground up with any changes we introduce.

This framework also gives us an opportunity to show different Reference Architectures and a sane example on how to start with OpenStack using Chef.

With the master branch of the cookbooks, which is currently tied to the base OpenStack Ocata release, this supports deploying to Ubuntu 16.04 and CentOS 7 in monolithic, or allinone, and non-HA multinode configurations with Neutron. The cookbooks support a fully HA configuration, but we do not test for that as there are far numerous paths to HA.

Prerequisites

  • ChefDK 1.0 or later for a relatively recent Berkshelf
  • Vagrant 1.9 or later with VirtualBox or some other provider

Getting the Code (this repo)

$ git clone https://github.com/openstack/openstack-chef-repo.git
$ cd openstack-chef-repo

The OpenStack cookbooks by default use encrypted data bags for configuring passwords. There are four data bags : user_passwords, db_passwords, service_passwords, secrets. There already exists a data_bags/ directory, so you shouldn't need to create any for a proof of concept. If you do, something is wrong. See the Data Bags doc for the gory details.

Supported Deployments

For each deployment model, there is a corresponding file in the doc/ directory. Please review that for specific details and additional setup that might be required before deploying the cloud.

Rake Deploy Commands

These commands will produce various OpenStack cluster configurations, the simplest being a monolithic Compute Controller with Neutron (allinone). These deployments are not intended to be production-ready, and will need adaptation to your environment. This is intended for development and proof of concept deployments.

For CentOS, set the environment variable REPO_OS=centos7. Ubuntu is the default.

Everything self-contained (allinone)

# allinone with Neutron
$ chef exec rake allinone

Access the machine

$ cd vms
$ vagrant ssh controller
$ sudo su -

Multiple nodes (non-HA)

# Multinode with Neutron (1 controller + 1 network + 2 compute nodes)
$ chef exec rake multi_node

Access the Controller

$ cd vms
$ vagrant ssh controller
$ sudo su -

Access the Network Node

$ cd vms
$ vagrant ssh network
$ sudo su -

Access the Compute nodes

$ cd vms
$ vagrant ssh compute1
# OR
$ vagrant ssh compute2
$ sudo su -

Testing The Controller

# Access the controller as noted above
$ source /root/openrc
$ nova --version
$ openstack service list && openstack hypervisor list
$ openstack image list
$ openstack user list
$ openstack server list

Working With Security Groups

To allow SSH access to instances, a security group is defined as follows:

$ openstack security group list
$ openstack security group list default
$ openstack security group create allow_ssh --description "allow ssh to instances"
$ openstack security group rule create allow_ssh --protocol tcp --dst-port 22:22 --remote-ip 0.0.0.0/0
$ openstack security group list allow_ssh

Working With Keys

To allow SSH keys to be injected into instance, a key pair is defined as follows:

# generate a new key pair
$ openstack keypair create mykey > mykey.pem
$ chmod 600 mykey.pem
$ openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey
# verify the key pair has been imported
$ openstack keypair list

Booting up a cirros image on the Controller

$ openstack server create --flavor 1 --image cirros --security-group allow_ssh --key-name mykey test

Wait a few seconds and the run openstack server list if Status is not Active, wait a few seconds and repeat.

Once status is active you should be able to log in using SSH, or vagrant ssh <vm_name>

$ ssh cirros@<ip address from openstack server list output>

Accessing The OpenStack Dashboard

If you would like to use the OpenStack dashboard you should go to https://localhost:9443 and the username and password is admin/mypass.

Verifying OpenStack With Tempest

If you log in to the controller machine you can test via the most recent Tempest release.

$ cd vms
$ vagrant ssh <controller>
$ sudo su -
root@controller:~ cd /opt/tempest
root@controller:/opt/tempest$ ./run_tempest.sh -V --smoke --serial

[-- snip --]

tempest.tests.test_wrappers.TestWrappers
    test_pretty_tox                                                       1.68
    test_pretty_tox_fails                                                 1.03
    test_pretty_tox_serial                                                0.61
    test_pretty_tox_serial_fails                                          0.55

Ran 233 tests in 13.869s

OK
Running flake8 ...
root@controller:/opt/tempest#

Cleanup

To remove all the nodes and start over again with a different environment or different environment attribute overrides, using the following rake command.

$ chef exec rake destroy_machines

To refresh all cookbooks, use the following commands.

$ rm -rf cookbooks
$ chef exec rake berks_vendor

To clean up everything, use the following rake command.

$ chef exec rake clean

Tools

See the doc/tools.md for more information.

Data Bags

Some basic information about the use of data bags within this repo.

# Show the list of data bags
$ chef exec knife data bag list -z
db_passwords
secrets
service_passwords
user_passwords

# Show the list of data bag items
$ chef exec knife data bag show db_passwords -z
cinder
dash
glance
horizon
keystone
neutron
nova

# Show contents of data bag item
$ chef exec knife data bag show db_passwords nova -z
Encrypted data bag detected, decrypting with provided secret.
nova: mypass
id:   nova

# Update contents of data bag item
# set EDITOR env var to your editor. eg. EDITOR=vi
$ chef exec knife data bag edit secrets dispersion_auth_user -z

Data Bag Default Values

db_passwords are set to "mypass" secrets are set to "_token" service_passwords are set to "mypass" user_passwords are set to "mypass"

Default Encrypted Data Bag Secret

The default secret is stored here .chef/encrypted_data_bag_secret and referenced by .chef/knife.rb.

When we say defaults, we mean that they are known by everyone with access to this repository. Change these to something else before deploying for real.

Known Issues and Workarounds

Windows Platform

When using this on a Windows platform, here are some tweaks to make this work:

  • In order to get SSH to work, you will need an SSL client installed. You can use the one that comes with Git for Windows. You will need to append C:\Program Files (x86)\Git\bin; to the system PATH.

TODOs

  • Support for floating IPs
  • Better instructions for multi-node network setup
  • Easier debugging. Maybe a script to pull the logs from the controller.

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.