OpenStack® Designate allows the Rackspace Technology OpenStack Private Cloud users to use Domain Name Server (DNS) services in their environment.

Rackspace is launching OpenStack® Train v20, which is the latest open-source software release as part the OpenStack Ansible project.

Using Terraform with Rackspace Public Cloud

Handling a huge scale of infrastructure requires automation and infrastructure as code. Terraform is a tool that helps to manage a wide variety of systems including dynamic server lifecycle, configuration of source code repositories, databases, and even monitoring services. Terraform uses text configuration files to define the desired state of infrastructure. From those files, Terraform provides information on the changes to be made based on the current state of that infrastructure, and can make those changes.

The OpenStack live migration process is one of the most vital processes in the compute drivers, but it is also easily one of the most complex. This complexity drove my curiosity to better understand what is happening under the hood, and I wanted to share that knowledge with you. In this article, we dive deep into the OpenStack codebase, but first, the article does assume a few things.

In our previous article, we began to trace the process of a live migration and explored how Nova API receives this call, processes it, injects basic information about the instance and eventually passes it to our next destination, Conductor. Before we continue the discussion, let’s again review our assumptions.

In our previous [article]({% post_url 2018-04-20-Code-Dive-Openstack-Live-Migrations-Part-2 %}), we dove deeply into the Live Migration process by looking at how Conductor passes data back and forth between Scheduler and the Source and Destination Compute Nodes. We have found a host machine at this point and verified that all of our preliminary checks will pass.

It has been a while since the last official release of Syntribos - a whole year, in fact! But we haven’t been sitting idle. This article explores the new capabilities offered by this latest release.

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.

One of the many benefits of using and working with Python is its ability to introspect itself. This empowers us to write and use tools to analyze the projects we use and write. Tools written in Python can use the built-in ast module to parse and analyze other Python code into an “_A_bstract _S_yntax _T_ree”. Perhaps you’ve heard of Flake8, PyFlakes, PyLint, Radon, or another tool that provides style checking, lint discovery, or complexity computation? They all use the AST to provide that functionality. There’s also a tool called Bandit that uses the AST to provide static security analysis of Python programs.

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: https://news.netcraft.com/archives/2016/05/26/may-2016-web-server-survey.html