In my previous series of articles on OpenStack networking, I mentioned that there are ways of doing things in the virtual world that can’t be done in the physical world. Because of that, we shouldn’t let the physical server limitations control our thinking in the virtual world -- but often we do.

A Performance comparison: Apache vs NGINX and OpenStack Keystone

In a previous article, I showed how to configure keystone to run behind NGINX instead of current recommended configuration using Apache. Since its inception, NGINX has enjoyed significant growth in the web server space. Netcraft monthly data web server market share for NGINX has grown significantly since its introduction. Data for May 2016 can be found at: http://news.netcraft.com/archives/2016/05/26/may-2016-web-server-survey.html

Run OpenStack Keystone and Horizon using NGINX on Ubuntu 16.04

I previously wrote an article showing how to convert OpenStack from using an Apache server for both Keystone and the Horizon interface. Since that article was written, OpenStack has moved to the Mitaka release, and Unbuntu has moved to a new long term release "Ubuntu 16.04 - xenial". These two releases bring a number of changes to the configuration. In this article, I show you how to make the transition to ngix running these newer releases.

In my previous series of articles about installing OpenStack from source, we installed keystone as a standalone application. This technique has been deprecated in the Kilo release in favor of running the keystone server, as a web server gateway interface (wsgi) service behind the Apache server. This allows for each Apache thread to start its own separate keystone thread. Example configuration files are available in the httpd directory in the cloned keystone repo. This article is a how to setup both keystone and the horizon dashboard to run under Nginx.

This is the sixth and final installment in a series demonstrating how to install OpenStack from source. The five previous articles:

• Install Keystone
• Install Glance and Neutron
• Install Nova
• Install Neutron on the Network node
• Install the Compute node

Previously we installed the Identity service (keystone), Image service (glance), Networking service (neutron), and the Compute service (nova) onto the controller node. We also installed neutron onto the network node and nova and neutron onto the compute node. In this section, we turn our attention to finishing up by installing the Volume service (cinder) and dashboard (horizon) onto the controller node.

This is the fifth installment in a series of installing OpenStack from source. The four previous articles can be found here:

• Install Keystone,
• Install Glance and Neutron
• Install Nova
• Install Neutron on the Network node

We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node, and then we turned our attention to the network node to install the neutron agents to support the network layers two and three. Now, we turn our attention to the compute node to install both neutron and nova.

This is the fourth installment, in a series showing how to install OpenStack from source. In the three previous articles:

• Install Keystone
• Install Glance and Neutron
• Install Nova

We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node. In this section, we turn our attention to the network node, to install the neutron agents to support network layers two and three.

In article one of this series, we started installing OpenStack from source, and, in article two of this series, we continued the process by installing glance and neutron onto the controller node.

In the first article of this series, we started installing OpenStack from source. We installed keystone and populated it with some basic information including a Services project and an admin user for our new OpenStack install. Additionally, in an initial script we setup users and directories for the upcoming installs of the Image service (glance), Networking service (neutron), Compute service (nova) and Volume service (cinder). Now, let's continue and install and start the glance process on the controller node.

Installing OpenStack has always been challenging. Due to the complexity and varity of design choices involved in setting up OpenStack, automated installers are rare. For those who need a small but realistic setup, to be used either for development or learning, a manual installation using the desired distribution's packages has been the typical solution. Distribution packages simplify the process, however they come with compromises.

Software Defined Networks in the Havana release of Openstack – Part 2

In the first article in this series, we looked at a simple OpenStack setup with one controller node, one compute node, and one network node. Two tenants had been created with two simple networks. In this article we will turn our attention to the network paths for each of the three VMs that were created. The diagrams in the first article are useful in understanding this discussion.

Discussion hen continues with the first half of the iptables chains that are interjected between the VM and the Open vSwitch process (OVS) on the compute node. In order to keep these articles in bite sized chunks, we will end this s ection after looking at the first two iptables chains, those starting with neutron – which manage the security group rules, the next article continue s through the iptables chains looking at those starting with nova and concludes by reviewing how two different types of packets progress through these chains.