[UPDATE]
My Rackspace colleague, James Thorne, has a post on his extremely useful blog that uses the 4.2.1 release of the Rackspace Private Cloud (RPC) to install the Havana release of OpenStack on a laptop using Vagrant and Chef. Since James’ post actually uses the GA version of RPC and includes Neutron Networking, I highly recommend that readers use the instruction in his post instead.
Introduction
Not long ago, I posted an article outlining how you could install a HA OpenStack environment on your laptop or workstation, using Vagrant with a virtualization tool, such as VirtualBox, VMware Workstation, or VMware Fusion. That post borrowed heavily from another post by my Rackspace colleague, James Thorne and was designed to allow someone to get up and running quickly on OpenStack for testing and demonstrating high-availability. Since then, a new release of OpenStack, code-named Havana, has been released, with some important new features.
In this post, I’ll walk through installing OpenStack (Havana) on a laptop using Vagrant with VirtualBox, Workstation, or Fusion; this deployment should be suitable for testing and demos. However, instead of deploying a pair of HA Controllers, I’ll provide instructions on deploying a single controller but throw in a Cinder Volume node as a bonus. Also, instead of having you “flip” back and through between mine and James’ blog, I’ll put the bulk of the instructions and commands into this post; however, I am borrowing heavily from James and the great work he has put into his blog.
Before we begin the installation, here are some notes and caveats you should be aware of:
- We will be using Opscode’s Chef to deploy an early access release of the Rackspace Private Cloud (RPC), version 4.2. RPC 4.2 is a beta product that is based on the downstream Havana trunk. So although Rackspace has changed the Horizon dashboard skin to show the RPC logo, the underlying code is 100% OpenStack trunk.
- Because Rackspace is not currently supporting the Heat project in its early access release of RPC, Heat is not included in the generic install. However, in the post, I will walk you through how to add Heat to your deployment.
- Swift object storage is not part of this install. I’ll update this post or writeup a new post on how to install Swift when I’ve had more time to potentially work on an entire blog series on the Swift project.
- While Neutron Networking is part of RPC 4.2 and the recommended networking project to use in production, I am going to walk though the old-style Nova Networking in this post. I am primarily doing this because of some issues I am having getting Neutron to work with my particular setup; I expect to update this post as soon as I have those issues worked out. My thought is to get this post out there so folks can start playing with other aspects of OpenStack, like the new dashboard in Havana, Heat, Ceilometer, Cinder, etc..
- Since RPC 4.2 is an early access release, Rackspace does not provide support for the product; again, think of it as a beta product. Full support will be available next month when RPC 4.2.1 is generally available.
Setting Up Your Lab/Demo Environment
So what are we building on your laptop or PC to test OpenStack? The sample Rackspace Private Cloud reference architecture below shows the 5 node environment we will be creating, with 1 Chef server node, 1 Controller node, 2 Nova Compute nodes, and 1 Cinder node. Note that most OpenStack services will run on our Controller node.
Installing And Configuring Vagrant
- The first step is to install Vagrant; I recommend using version 1.3.4 or later.
- Then install whichever virtualization software (VirtualBox, VMware Fusion, VMware Workstation) you intend to use as your Vagrant provider, including any Vagrant plugin that is required.
[You can get more details on the above steps at James’ blog]
- Download the Vagrant box appropriate for the virtualization software you have chosen. In this case, we will be using the precise64 Vagrant box to install Ubuntu 12.04 LTS on all our nodes:
- Create a directory for this environment (Below is an example) and create the initial Vagrantfile:
mkdir -p ~/vagrant/havana
cd ~/vagrant/havana
vagrant init
- Configure your favorite editor (Mine is vim, which is what I use for my example below):
apt-get install vim -y
export EDITOR=$(which vim)
- Open the newly created Vagrantfile and REPLACE the contents with the following entries (Note that if necessary, you can scroll down the text box to see the entire Vagrantfile):
[You can also access the Vagrantfile here.]
- Now it’s time to start-up your Vagrant environment:
[For VirtualBox]: vagrant up
[For VMware Fusion]: vagrant up –provider vmware_fusion
[For VMware Workstation]: vagrant up –provider vmware_workstation
vagrant status (To Confirm all nodes are running)
Setting Up Chef Server
- ssh to your chef node and log on as root (password is vagrant):
vagrant ssh chef
su
- Then install Chef Server:
wget https://raw.github.com/rcbops/support-tools/master/chef-install/install-chef-server.sh
chmod +x install-chef-server.sh
./install-chef-server.sh
[Not sure why, but I’ve had to run the install 2x every time to get everything installed correctly; I suggest you do the same]
- After install, re-source your environment so you can use knife commands:
- Install the RPC 4.2 Cookbooks:
apt-get install git -y
git clone https://github.com/rcbops/chef-cookbooks.git
cd chef-cookbooks
git checkout v4.2.0
git submodule init
git submodule sync
git submodule update
knife cookbook upload -a -o cookbooks
knife role from file roles/*rb
- Since RPC 4.2 does not currently include the Heat project, we will need to manually add the Heat role to the “run_list” for our “single-controller” role:
- Add the following line to the run_list:
- Next, create the RPC 4.2 Chef Environment:
- Open the newly created Environment file and REPLACE the contents with the following entries (Note that if necessary, you can scroll down the text box to see the entire Vagrantfile):
[You can also access the Environment file here.]
Setting Up The OpenStack Nodes
- Create a password-less SSH Public/Private key, hitting enter to accept all defaults.
- Copy the SSH Public key to all the OpenStack nodes:
ssh-copy-id root@controller
ssh-copy-id root@compute1
ssh-copy-id root@compute2
ssh-copy-id root@cinder
- Setup your CHEF_SERVER_URL Environment variable:
- Now install and register the Chef client on each node and also set the RPC 4.2 Chef Environment on each node:
[Please note that WordPress (which hosts this blog) is not properly formatting double dashes; for the “knife bootstrap” commands below, please type the commands instead of doing a copy and paste OR copy and paste and then delete the dashes and re-enter them manually]
knife bootstrap controller –environment rpcv420 –server-url $CHEF_SERVER_URL
knife bootstrap compute1 –environment rpcv420 –server-url $CHEF_SERVER_URL
knife bootstrap compute2 –environment rpcv420 –server-url $CHEF_SERVER_URL
knife bootstrap cinder –environment rpcv420 –server-url $CHEF_SERVER_URL
- Then add the appropriate OpenStack roles to each node:
[Please note that WordPress (which hosts this blog) is not properly formatting single quotes; for the “knife node run_list” commands below, please type the commands instead of doing a copy and paste OR copy and paste and then delete the quotes and re-enter them manually]
knife node run_list add controller ‘role[single-controller]’
knife node run_list add compute1 ‘role[single-compute]’
knife node run_list add compute2 ‘role[single-compute]’
knife node run_list add cinder ‘role[cinder-volume]’
Installing OpenStack
- ssh to each of your OpenStack nodes and log on as root (I prefer doing so from the chef node since that logs me on as root automatically).
[I recommend performing the install in the following order – controller, compute1, compute2, cinder]
Once you’ve gone through all the nodes, RPC 4.2 (powered by OpenStack Havana) should be up and running on your laptop/workstation.
Setting Up the Cinder-volume Node
The following steps will configure a 4 GB test loopfile that you can use for Cinder block storage services. You can find more details in the OpenStack Block Storage Service Administration Guide.
- ssh to your cinder node and log on as root (If you are not already there from the install):
- Create a 4 GB test loopfile:
- Mount the test loopfile:
- Initialize it as a lvm ‘physical volume’:
- Create the lvm ‘volume group’:
- Confirm the cinder-volume has been created (you should see a 4 GB cinder volume):
- Restart the cinder-volume service on the cinder node
- ssh to your controller node and log on as root to restart the other cinder services:
service cinder-api restart
service cinder-scheduler restart
- Now we are going to create a test volume, but first you may have to source the “openrc” file to give yourself sufficient credentials to use the OpenStack APIs:
- Create a 1 GB Cinder volume and confirm it was created:
[Please note that WordPress (which hosts this blog) is not properly formatting double dashes; for the “cinder create” command below, please type the command instead of doing a copy and paste OR copy and paste and then delete the dashes and re-enter them manually]
cinder create –display_name testvol 1
cinder list
- At this point, you can choose to conserve some resources on your laptop by logging off your OpenStack nodes into your laptop’s or workstation’s shell and shutting down the chef node:
Exit (Until you are logged off all OpenStack nodes)
vagrant halt chef
Post-Installation Configuration
Before logging on to the Horizon dashboard to play around or to perform a demo, let’s do some initial configuration.
- If you are not currently logged into one of the OpenStack nodes as root, do so now (I usually log on to the controller node); you may have to source the “openrc” file to give yourself sufficient credentials to use the OpenStack APIs:
- Upload an image to Glance and confirm upload (The example below will upload a small Linux image called “cirros”):
[Please note that WordPress (which hosts this blog) is not properly formatting double dashes; for the “glance image-create” command below, please type the commands instead of doing a copy and paste OR copy and paste and then delete the dashes and re-enter them manually]
glance image-create –name cirros-0.3.1-x86_64 –is-public true –container-format bare –disk-format qcow2 –copy-from http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img
glance image-list
- Now we’ll add some rules to our default security group to allow “ping” and “ssh” to the Cloud instances we’ll be launching:
nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
- Next we’ll create a floating IP pool, called “public,” with IP addresses that can be assigned to your instances to allow external (from your laptop or workstation) access (The example below creates a pool of 16 contiguous addresses, called “public,” in the 192.168.236.0/24 network):
Taking The Dashboard For A Spin
Time to spin up your first Cloud instance and attach a persistent block volume to it.
- From your web browser, launch the Horizon dashboard via the Controller node IP address:
[Note again that the dashboard has the Rackspace Private Cloud skin; however, it is still essentially the Horizon dashboard.]
- Log in as the Cloud Administrator using User Name: Admin and Password: secrete.
- Navigate to the “Project” tab on the left-hand side of the screen and you’ll see an overview of this project/tenant:
Spinning Up And Configuring Instances
- Go to “Instances” and lick “Launch Instance.” Choose the cirros image, you just uploaded to Glance, to launch your first Cloud instance and then watch the dashboard to see the instance “Spawning” until it is “Running”:
- Assign a floating IP address to your instance by going to “Access & Security” and choosing the “Floating IPs” section. Click on the “Allocate IP To Project” button and from the dialog box, allocate an IP from the public floating pool you created earlier.
- Once a floating IP address has been allocated, assign it to the Cloud instance by clicking on the “Associate” button and choosing the new IP address and the instance you created earlier:
- Go back to the “Instances” page and note that your instance now has 2 IP addresses assigned to it, including the floating IP address:
- From your workstation, ssh to the instance using the floating IP address and log on as the user “cirros.” (The example below uses 192.168.236.65 as the floating IP address):
ssh cirros@192.168.236.65
Password: cubswin:)
- Launch a second Cloud instance using the cirros image or some other image you may have uploaded:
- Navigate back to the “Admin” tab on the left-hand side of the screen and move to the “Hypervisors” page. You should see that the 2 instances you created are distributed across the 2 Compute nodes as would be expected based on the behavior of the Nova-scheduler:
Creating And Attaching A Cinder Volume
- Go the “Volumes” page and note the Cinder volume we created earlier:
- Create a new volume by clicking on the “Create Volume” button and filling out the “Volume Name” and “Size (GB)” fields in the dialog box (See example below):
- Attach 1 of the 2 volumes to an instance by clicking on the “Edit Attachments” button for the chosen volume; choose an instance in the “Attach to Instance” field and fill out the “Device Name” field before clicking on the “Attach Volume” button. (See example below):
Conclusion
- When you are done, you can shutdown all OpenStack nodes with a single command:
- Alternatively, you can suspend all OpenStack nodes with a single command:
You now have an environment to play with and to demo OpenStack on your laptop or workstation. For more information on how to configure and to use OpenStack, I recommend looking at the Documentation sections of the OpenStack Foundation website and the Rackspace Private Cloud Knowledge Center. To dive deeper into configuring OpenStack with Chef and vagrant, I recommend perusing the Professional OpenStack website and also purchasing the “OpenStack Cloud Computing Cookbook” by my colleagues, Cody Bunch and Kevin Jackson.
Related articles
- OpenStack Havana Heats Up the Cloud (eweek.com)
Cloud Architect Musings 
Reblogged this on Virtualized Geek and commented:
I don’t reblog as often but this is flat out cool and needs as much exposure as possible. Thanks Ken!
Keith,
Thank you.
Ken
Reblogged this on Capacitive Flux and commented:
Using Vagrant and Chef to build an Openstack (Havana) environment
[…] Deploy OpenStack (Havana) On Your Laptop Using Vagrant And Chef | Cloud Architect Musings. […]
[…] OpenStack Havana deployment using Vagrant and Chef to deliver the Rackspace Private Cloud edition: https://cloudarchitectmusings.com/2013/12/01/deploy-openstack-havana-on-your-laptop-using-vagrant-and… and I can tell you that this is a massive time […]
Hi,
Every thing went well until I tried to run chef-client on controller
Error I’m seeing is
FATAL: LoadError: cannot load such file — chef/dsl/data_query
Please help.
Thanks in advance.
I’m elaborating the error I have reported. Please find detailed error below.
Please note I’m using I’m trying this on 32bit laptop.
I changed in vagrantfile as precise32
================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/dsh/libraries/provider_dsh_group.rb
================================================================================
LoadError
———
cannot load such file — chef/dsl/data_query
Cookbook Trace:
—————
/var/chef/cache/cookbooks/dsh/libraries/provider_dsh_group.rb:21:in `’
Relevant File Content:
———————-
/var/chef/cache/cookbooks/dsh/libraries/provider_dsh_group.rb:
14: # distributed under the License is distributed on an “AS IS” BASIS,
15: # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
16: # See the License for the specific language governing permissions and
17: # limitations under the License.
18: #
19:
20: require ‘chef/provider’
21>> require ‘chef/dsl/data_query’
22: require “pp”
23: require “set”
24:
25: class Chef
26: class Provider
27: class DshGroup < Chef::Provider
28: include Chef::DSL::DataQuery
29:
30: def load_current_resource
[2013-12-04T21:45:20+00:00] ERROR: Running exception handlers
[2013-12-04T21:45:20+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2013-12-04T21:45:20+00:00] ERROR: Exception handlers complete
[2013-12-04T21:45:20+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2013-12-04T21:45:20+00:00] FATAL: LoadError: cannot load such file — chef/dsl/data_query
Hello,
I have the same problem as Ajju with precise64 :
[2013-12-05T02:59:42+00:00] ERROR: Running exception handlers
[2013-12-05T02:59:42+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2013-12-05T02:59:42+00:00] ERROR: Exception handlers complete
[2013-12-05T02:59:42+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2013-12-05T02:59:42+00:00] FATAL: LoadError: cannot load such file — chef/dsl/data_query
Thanks for your help
Guidtz
Hello,
i have the same problem as Ajju with precise64 :
[2013-12-05T02:59:42+00:00] ERROR: Running exception handlers
[2013-12-05T02:59:42+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2013-12-05T02:59:42+00:00] ERROR: Exception handlers complete
[2013-12-05T02:59:42+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2013-12-05T02:59:42+00:00] FATAL: LoadError: cannot load such file — chef/dsl/data_query
Thanks
Yes, I am seeing the same thing. I’ll troubleshoot this Thursday morning.
Any luck khui? Thanks in advance.
Yes, looks like it’s a WordPress issue. WordPress is not properly formatting single quotes or double dashes. For the “knife bootstrap” and “knife node run_list add” commands, please type the commands out instead of doing a copy and paste.
Looks like it’s a WordPress issue. WordPress is not properly formatting single quotes or double dashes. For the “knife bootstrap” and “knife node run_list add” commands, please type the commands out instead of doing a copy and paste.
I tried again. No Luck. I faced same issue. I remember single quote in knife command was changed to a comma when I did for first time.
Command did not work so I changed it back to single quote then command worked.
This don’t seems to be issue.
DSL recipe is the issue. Need to tell this to Chef guys.
I don’t saw any other reporting this.
On opscode I found this recipe docs etc., but no issues.
I tried again. No Luck. I faced same issue. I remember single quote in knife command was changed to a comma when I did for first time.
Command did not work so I changed it back to single quote then command worked.
This don’t seems to be issue.
DSL recipe is the issue. Need to tell this to Chef guys.
I don’t saw any other reporting this.
On opscode I found this recipe docs etc., but no issues.
Looks like the issue is that the dsh and some other recipes involved need Chef 11.
Which is cool, except some versions of vagrant force the 1.8.7 ruby and the associated chef 10.0.4 gems.
So, when you go to knife bootstrap it installs the old version of chef that doesn’t support dsh.
I was able to work around the error by dropping
knife[:bootstrap_version] = ‘11.4.0-1’
into root@chef:/root/.chef/knife.rb before the bootstrap.
Or just pulling the chef deb from opscode.com.
That is correct. The recipes we use for RPC are based on Chef 11.04. Thanks for the workaround.
As I said I’m using precise 32. So chef installer in this blog failed as per Hui’s Suggestion I downloaded chef_11.4.0-1.debian.6.0.5_i386.deb and did
dpkg. Which passed.
Q chef_11.0.0-1.debian.6.0.5_i386.deb this chef server works? I mean is this 11.04 as needed?
Q what should I do after dpkg or before dpkg to install and configure chef/knife?
Thanks in advance, WEnd screwed still struggling. Please help!
Ajiu,
OpenStack is only supported officially on 64-bit Linux.
[…] By Kenneth Hui: Deploy OpenStack (Havana) On Your Laptop Using Vagrant And Chef […]
I’m running into the same issue over and over again- during the bootstrap it installs the chef client fine, but it can’t connect to the chef server. It’s trying the DHCP-assigned IP instead of the static one thats in the host file and I get this error:
controller
controller There was a network error connecting to the Chef Server:
controller Connection refused – Connection refused connecting to 10.0.2.15:443 for /clients, giving up
controller
controller
controller
controller
controller Relevant Config Settings:
controller ————————-
controller chef_server_url “https://10.0.2.15:443”
controller
controller If your chef_server_url is correct, your network could be down.
if i change it in the knife.rb on the node, it will connect ok, but it gets set back to the other IP when the bootstrap is run.
Ideas?
Hi,
Now I’m trying this on a 64bit Ubuntu blade. Struck in same stage like you.
I wonder after successful installation also there no chef-server service. Its ngnix.
Some how I could able to knife configure and create client.
But now struck with uploading cookbooks.
Hui,
ngnix is used as webserver or any thing wrong with my install?
I believe this is the fix:
https://tickets.opscode.com/browse/CHEF-4069
I had the same problem. In my first run, I copied the command and replaced the dashes – that failed with the error. After that I wrote the command by hand and it works successfully.
[…] Deploy OpenStack (Havana) On Your Laptop Using Vagrant And Chef (cloudarchitectmusings.com) […]
“Go to “Instances” and lick “Launch Instance.” ” :). Excellent article though.
I encountered “ERROR: Can’t find network management”, following hints from https://community.rackspace.com/products/f/45/t/1514 , I ran “chef-client -E rpcv420” instead of “chef-client” and it worked.
I get stuck on
knife bootstrap controller -environment rpcv420 -server-url $CHEF_SERVER_URL
I get an error
controller [2014-01-03T13:41:21+00:00] FATAL: Errno::ECONNREFUSED: Connection refused – Connection refused connecting to : for erver-url/clients, giving up
I typed the command in by hand so as not to have the WordPress issue. If I echo $CHEF_SERVER_URL I see
https://chef:443
Is this due to the validator key being in the wrong place or something?
I found if edit my ~/.chef/knife.rb at the chef_server_url line to use https://chef:443 my chef server stopped overwriting the client.rb on the nodes with https://10.0.2.15:443
I also changed my /etc/chef-server/chef-server.rb file.
I’m a newbie. Ran in the same problem as Tyler:
controller Connection refused – Connection refused connecting to 10.0.2.15:443 for /clients, giving up
I tried the fixes suggested by Joe H (https://tickets.opscode.com/browse/CHEF-4069), but that didn’t work either. Was there a final fix for this?
Just a +1 from me: I’m also pretty new and am likewise stuck with the connection refused error on the clients. My CHEF_SERVER_URL is set to https://chef:443 but it’s somehow taking the IP address from somewhere instead. Any ideas on the correct fix?
Bootstrapping Chef on controller
controller Starting Chef Client, version 11.6.0
controller Creating a new client identity for controller using the validator key.
controller [2014-02-06T22:20:25+00:00] ERROR: Connection refused connecting to 10.0.2.15:443 for /clients, retry 1/5
controller [2014-02-06T22:20:30+00:00] ERROR: Connection refused connecting to 10.0.2.15:443 for /clients, retry 2/5
controller [2014-02-06T22:20:35+00:00] ERROR: Connection refused connecting to 10.0.2.15:443 for /clients, retry 3/5
controller [2014-02-06T22:20:40+00:00] ERROR: Connection refused connecting to 10.0.2.15:443 for /clients, retry 4/5
controller [2014-02-06T22:20:45+00:00] ERROR: Connection refused connecting to 10.0.2.15:443 for /clients, retry 5/5
controller
controller ================================================================================
controller Chef encountered an error attempting to create the client “controller”
controller ================================================================================
controller
controller
controller Network Error:
controller ————–
controller There was a network error connecting to the Chef Server:
controller Connection refused – Connection refused connecting to 10.0.2.15:443 for /clients, giving up
controller
controller
controller
controller Relevant Config Settings:
controller ————————-
controller chef_server_url “https://10.0.2.15:443”
controller
controller If your chef_server_url is correct, your network could be down.
controller
controller
controller
controller [2014-02-06T22:20:50+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
controller Chef Client failed. 0 resources updated
controller [2014-02-06T22:20:50+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Sorry I haven’t had a chance to check on this. I will take a look over the weekend to see what the issue may be. Thank you for your patience.
I’ve been doing few set up with chef for the last few days, and I noticed that the chef server url must be in form of domain name. From the ip address I saw in the error, they are likely chef server’s ip address, but it is likely a NAT IP. Therefore, the issues may relate to the following:
1. controller does not know the NAT IP, Therefore, you will have to setup port forwarding from controller node to talk with NAT.
2. hostname resolver. Just add the chef server into controller’s hostname
3. incorrect chef-server-url in .chef/knife.rb, so make sure hostname is used in the chef server url.
All,
I posted an update to this post recommending that folks use the instructions on my colleague, James Thorne’s blog at http://goo.gl/kPhxeI since it uses the GA version of RPC and includes Neutron networking. It should also alleviate some of the issues that folks have been seeing.
Ken
I “fixed” hacked the chef_server_url in the install script with the following.
“`
#PRIMARY_INTERFACE=$(ip route list match 0.0.0.0 | awk ‘NR==1 {print $5}’)
PRIMARY_INTERFACE=eth1
MY_IP=$(ip addr show dev ${PRIMARY_INTERFACE} | awk ‘NR==3 {print $2}’ | cut -d ‘/’ -f1)
CHEF_UNIX_USER=${CHEF_UNIX_USER:-root}
“`
Decided to start from scratch when I found this but a vagrant destroy makes that easy.
This seems to work for me – many thanks for that! 🙂
I also specifically had to add the roll[“heat-all”] AFTER roll[“keystone”] in the single-controller role.
Thanks so much! I got it up and running, and it is pretty awesome.
I did run into the “10.0.2.15” convergence error that some of the other commenters encountered, but I resolved it by editing /etc/chef-server/chef-server.rb and replacing “https://10.0.2.15:443” with “https://chef:443” in a couple places:
node.override[“chef_server”][“nginx”][“url”] = “https://chef:443”
…
node.override[“chef_server”][“bookshelf”][“url”] = “https://chef:443”
Then, I ran `chef-server-ctl reconfigure` on the chef node to put the changes into effect before running chef-client on the nodes.
Thanks! I got it up and running with a couple modifications to /etc/chef-server/chef-server.rb on lines 5 and 9, where 10.0.2.15 was hard-coded:
node.override[“chef_server”][“nginx”][“url”] = “https://chef:443”
…
node.override[“chef_server”][“bookshelf”][“url”] = “https://chef:443”
1) I did modification to install-chef-server-sh as follow:
# PRIMARY_INTERFACE=$(ip route list match 0.0.0.0 | awk ‘NR==1 {print $5}’)
PRIMARY_INTERFACE=eth1
CHEF_HOST=$(hostname)
MY_IP=$(ip addr show dev ${PRIMARY_INTERFACE} | awk ‘NR==3 {print $2}’ | cut -d
‘/’ -f1)
CHEF_UNIX_USER=${CHEF_UNIX_USER:-root}
# due to http://tickets.opscode.com/browse/CHEF-3849 CHEF_FE_PORT is not used ye
t
CHEF_FE_PORT=${CHEF_FE_PORT:-80}
CHEF_FE_SSL_PORT=${CHEF_FE_SSL_PORT:-443}
CHEF_URL=${CHEF_URL:-https://${CHEF_HOST}:${CHEF_FE_SSL_PORT}}
# CHEF_URL=${CHEF_URL:-https://${MY_IP}:${CHEF_FE_SSL_PORT}}
This code updated hostname instead of IP address which reduced occurance of errors pertaining to hostname entry.
2) I have also updated the ‘roles[head-all]’ in run_list after Keystone
3) when I am executing chef-client in controller node, I am getting the “can’t find network management” error.
root@controller:~# chef-client
Starting Chef Client, version 11.6.0
resolving cookbooks for run list: [“osops-utils::packages”, “openssh”, “ntp”, “sosreport”, “rsyslog::default”, “hardware”, “osops-utils::default”, “rsyslog::server”, “mysql-openstack::server”, “openstack-monitoring::mysql-server”, “erlang::default”, “rabbitmq-openstack::server”, “openstack-monitoring::rabbitmq-server”, “keystone::setup”, “osops-utils::keepalived-timeouts”, “keystone::keystone-api”, “openstack-monitoring::keystone”, “heat::heat-setup”, “heat::heat-engine”, “heat::heat-api”, “heat::heat-api-cfn”, “heat::heat-api-cloudwatch”, “glance::setup”, “glance::registry”, “openstack-monitoring::glance-registry”, “glance::api”, “openstack-monitoring::glance-api”, “nova::nova-setup”, “nova-network::nova-controller”, “openstack-monitoring::nova-network”, “nova::scheduler”, “openstack-monitoring::nova-scheduler”, “osops-utils::centos-amqplib-keepalive-patch”, “nova::nova-conductor”, “openstack-monitoring::nova-conductor”, “nova::api-ec2”, “openstack-monitoring::nova-api-ec2”, “nova::api-os-compute”, “openstack-monitoring::nova-api-os-compute”, “cinder::cinder-setup”, “cinder::cinder-api”, “openstack-monitoring::cinder-api”, “cinder::cinder-scheduler”, “openstack-monitoring::cinder-scheduler”, “nova::nova-cert”, “openstack-monitoring::nova-cert”, “nova::vncproxy”, “openstack-monitoring::nova-vncproxy”, “mysql::client”, “mysql::ruby”, “horizon::server”, “openstack-logging::default”, “ceilometer::ceilometer-setup”, “ceilometer::ceilometer-api”, “ceilometer::ceilometer-collector”, “ceilometer::ceilometer-central-agent”]
Synchronizing Cookbooks:
– keystone
– apache2
– osops-utils
– mysql
– monitoring
– database
– apt
– keepalived
– ceilometer
– rsyslog
– openstack-logging
– horizon
– sysctl
– nova
– nova-network
– yum
– cinder
– openssl
– dsh
– glance
– heat
– erlang
– rabbitmq
– rabbitmq-openstack
– build-essential
– openstack-monitoring
– xfs
– aws
– postgresql
– mysql-openstack
– collectd
– collectd-plugins
– monit
– hardware
– sosreport
– ntp
– iptables
– openssh
Compiling Cookbooks…
Recipe: build-essential::debian
* execute[apt-get-update-build-essentials] action run
– execute apt-get update
* package[autoconf] action install
– install version 2.68-1ubuntu2 of package autoconf
* package[binutils-doc] action install
– install version 2.22-6ubuntu1.1 of package binutils-doc
* package[bison] action install
– install version 1:2.5.dfsg-2.1 of package bison
* package[build-essential] action install
– install version 11.5ubuntu2.1 of package build-essential
* package[flex] action install
– install version 2.5.35-10ubuntu3 of package flex
Recipe: mysql::client
* package[mysql-client] action install
– install version 5.5.37-0ubuntu0.12.04.1 of package mysql-client
* package[libmysqlclient-dev] action install
– install version 5.5.37-0ubuntu0.12.04.1 of package libmysqlclient-dev
Recipe: mysql::ruby
* chef_gem[mysql] action install
– install version 2.9.1 of package mysql
[2014-04-30T10:30:11+00:00] ERROR: Can’t find network management
================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb
================================================================================
RuntimeError
————
Can’t find network management
Cookbook Trace:
—————
/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:48:in `rcb_exit_error’
/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:89:in `get_if_ip_for_net’
/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:71:in `get_ip_for_net’
/var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:33:in `from_file’
Relevant File Content:
———————-
/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:
41: # IP address is derived from required network, unless overridden
42: # Protocol defaults to “http”, path defaults to “/”. If a URI
43: # is specified, it overrides all other settings, otherwise it is
44: # composed from the individual components
45:
46: def rcb_exit_error(msg)
47: Chef::Log.error(msg)
48>> raise msg
49: end
50:
51: def rcb_safe_deref(hash, path, delim = “.”)
52: current = hash
53:
54: debug(“searching for #{path} in #{hash} with delimiter #{delim}”)
55: path_ary = path.split(delim)
56: path_ary.each do |k|
57: if current and current.has_key?(k)
[2014-04-30T10:30:11+00:00] ERROR: Running exception handlers
[2014-04-30T10:30:11+00:00] ERROR: Exception handlers complete
[2014-04-30T10:30:11+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
Chef Client failed. 9 resources updated
[2014-04-30T10:30:12+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
root@controller:~#
Kindly direct me where I went wrong and corrective actions,
Thanks.
I managed to install chef-client with Environment option (E) as mentioned by pellaeon. Thank you, pellaeon for your direction in this thread.
Command :
# chef-client -E rpcv420
root@chef:/etc/chef# ssh compute2
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)
* Documentation: https://help.ubuntu.com/
New release ‘14.04.2 LTS’ available.
Run ‘do-release-upgrade’ to upgrade to it.
Welcome to your Vagrant-built virtual machine.
Last login: Mon Mar 16 21:27:30 2015 from 192.168.236.10
root@compute2:~# chef-client -E rpcv420
Starting Chef Client, version 11.6.0
resolving cookbooks for run list: [“osops-utils::packages”, “openssh”, “ntp”, “sosreport”, “rsyslog::default”, “hardware”, “osops-utils::default”, “osops-utils::keepalived-timeouts”, “osops-utils::centos-amqplib-keepalive-patch”, “rsyslog::client”, “nova-network::nova-compute”, “openstack-monitoring::nova-network”, “nova::compute”, “openstack-monitoring::nova-compute”, “openstack-logging::default”, “ceilometer::ceilometer-compute”]
Synchronizing Cookbooks:
– osops-utils
– sysctl
– keepalived
– keystone
– apache2
– mysql
– monitoring
– database
– apt
– ceilometer
– rsyslog
– openstack-logging
– openstack-monitoring
– dsh
– openssl
– xfs
– aws
– build-essential
– postgresql
– yum
– cinder
– nova-network
– nova
– collectd
– collectd-plugins
– monit
– hardware
– sosreport
– ntp
– iptables
– openssh
Compiling Cookbooks…
[2015-03-16T22:00:06+00:00] WARN: Cannot find keystone/admin-api for role keystone-api
[2015-03-16T22:00:06+00:00] WARN: Cannot find keystone/internal-api for role keystone-api
[2015-03-16T22:00:06+00:00] WARN: Cannot find nova/api for role nova-api-os-compute
[2015-03-16T22:00:06+00:00] WARN: Cannot find nova/ec2-public for role nova-api-ec2
================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/nova-network/recipes/nova-compute.rb
================================================================================
NoMethodError
————-
undefined method `[]’ for nil:NilClass
Cookbook Trace:
—————
/var/chef/cache/cookbooks/nova/recipes/nova-common.rb:75:in `block in from_file’
/var/chef/cache/cookbooks/nova/recipes/nova-common.rb:69:in `from_file’
/var/chef/cache/cookbooks/nova/recipes/api-metadata.rb:20:in `from_file’
/var/chef/cache/cookbooks/nova-network/recipes/nova-compute.rb:28:in `from_file’
Relevant File Content:
———————-
/var/chef/cache/cookbooks/nova/recipes/nova-common.rb:
68: # TODO: need to re-evaluate this for accuracy
69: template “/root/openrc” do
70: source “openrc.erb”
71: owner “nova”
72: group “nova”
73: mode “0600”
74: vars = {
75>> “user” => keystone[“admin_user”],
76: “tenant” => keystone[“users”][keystone[“admin_user”]][“default_tenant”],
77: “password” => keystone[“users”][keystone[“admin_user”]][“password”],
78: “keystone_auth_uri” => ks_internal_endpoint[“uri”],
79: “nova_api_version” => “1.1”,
80: “keystone_region” => node[“nova”][“compute”][“region”],
81: “auth_strategy” => “keystone”,
82: “ec2_url” => ec2_public_endpoint[“uri”],
83: “ec2_access_key” => ec2_creds[“EC2”][keystone[‘admin_user’]][“access”],
84: “ec2_secret_key” => ec2_creds[“EC2”][keystone[‘admin_user’]][“secret”]
[2015-03-16T22:00:06+00:00] ERROR: Running exception handlers
[2015-03-16T22:00:06+00:00] ERROR: Exception handlers complete
[2015-03-16T22:00:06+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
Chef Client failed. 0 resources updated
[2015-03-16T22:00:06+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
When i’m trying to execute chef-client on chef nodes getting error, Could you help me
It could be a stupid question: what is the hypervisor that manage my instances in that virtualized architecture? I used vbox so i can virtualize every single node on my laptop, but what is the hypervisor on a single node that manage the instances dispatched by rackspace? is precise64 a kvm image?
It should be QEMU since you are leveraging nested VMs.
ty kenhui! I thought it yesternday reading RPC Sandbox docs, but i wasn’t sure if it is the same thing. Ty for your precious comment!!!
[…] OpenStack Havana deployment using Vagrant and Chef to deliver the Rackspace Private Cloud edition: https://cloudarchitectmusings.com/2013/12/01/deploy-openstack-havana-on-your-laptop-using-vagrant-and… and I can tell you that this is a massive time […]