OpenStack Installer (for RHEL-OSP) pt4

Hi Folks,

It only took us 4 posts to get to the brass tacks. I suppose I could have gotten here sooner, but I wanted to be sure I covered the bases properly along the way. The background, the lab, the host OS, and the installation of the application itself – otherwise the blog post would have been HUGE. (This still ended up being a larger post.) I’ve got one more huge suggestion before we start deploying nodes.

Label everything.

Specifically, label each system with it’s MAC address. And if you went the “NUC” plus “USB to ETH” adapter route, label those as well. All I did was use a label maker to print off the last 4 characters of the the MAC address – I didn’t actually print off the entire MAC address. I also labeled each of my little switches. I didn’t label my cable ends, but there are enough that I might actually go back and label those after all…

Why? First and foremost, the systems boot to the Installer using PXE, which in turn uses MAC addresses. So you’ll want to know that the system that you “think” is being deployed as a Cloud Controller isn’t actually being deployed as a Compute Node. Secondly, it makes troubleshooting much easier, and you know exactly which interface is being designated for what.. which is important as you divvy up different networks for different roles. Ok, enough

Create Subnets

The first think we’ll do is create subnets. This is done within the Installer, under the “We could actually do this during the “create deployment” steps, but I prefer to do it here. I’ve create 3 subnets – default, Tunnel, and Public. In the video example below, I meant to show subnets before deployments, but got ahead of myself. It’s ok though, it doesn’t hurt anything. I just think it’s a little easier to follow for those that are earlier in their learning journey to see subnets first, then see how they plug into the deployment. If you’re smart enough for OpenStack though, you’ll figure it out. 🙂 Besides, I walk you through it below..

Create Custom Parameter (optional)

This is optional for my fellow employees that want to filter out extra repo’s, but also serve as an example of how to create a parameter that gets read in.. I won’t get into it unless you really need me to as it has the potential to blow things up and is not supported. The vast majority of folks won’t need to do this.

Boot Settings

On to the hardware. A couple of notes on the systems that you expect to boot. You can handle it one of 2 ways:

  1. You can change the BIOS settings on all of your OpenStack nodes such that they boot to PXE first, then hard drive, no matter what. If the installer doesn’t have an assignment for the node, then the node will boot to “local” and you’re safe. The downside to this is left unattended, it will add about 20 seconds to the boot time. If you’re cool with that, I’d say this is likely the way to go. It certainly does not preclude you from using option 2 if you feel the need.
  2. You can also figure out the “F” key that triggers PXE boot on your nodes. On the Intel NUCs, I enabled PXE boot in BIOS, but I can also force it with F-12. If all else fails, I can type
    `cat /var/log/messages > /dev/sda; dd if=/dev/zero of=/dev/sda bs=512k count=1`

    and that will generally take care of the boot sector, thereby forcing PXE on it’s own. If you’re rebuilding systems for any reason, it’s a safe bet to wipe the boot sector, that way you know for sure the old system didn’t come back by accident.

Creating Subnets

  1. Go to the “Infrastructure” menu, then “subnets”
  2. There should already be a “default” subnet that matches your PXE/Mgmt network. Open it and double check that the information is correct. For example, the Gateway should equal the IP of the Installer node, as should the primary DNS. Optionally, you can put 8.8.8.8 as your secondary DNS. DHCP for IPAM and Boot mode are fine for the default subnet, just give it a range of IP addresses that is realistic for your deployment. (If you’re going to grow to 100 nodes, give it a big range, or vice-versa). If you made edits, click “submit”, otherwise, click “cancel”.
  3. Click on “New subnet”. Create your “publicly facing” subnet; I call mine “Public”. This will be your real or simulated public access. It will also be your “Floating IP” addresses. For my home lab, it happens to be my actual home network – the same subnet that sits behind my cable router. However, I don’t want competing DHCP servers, so I have specified “none” for IPAM and “static” for boot mode. So how does an instance get a floating IP from this subnet then, you ask? Easy – we simply give RHEL-OSP a range in this same subnet but outside of the DHCP range. Click “submit”.
  4. Click on “New subnet”. Create your “private instance” subnet; I call mine “Tunnel”. All instances that are part of the same tenant/project share the same private IP address. This is also where VXLAN or GRE tunneling happens, thus my subnet name.. This will likely be a non-routable subnet, so DNS is unnecessary. But you’ll still need a default gateway. DHCP is likely the way to go for IPAM and boot mode. RHEL-OSP (Neutron specifically) will handle the DHCP for you, so no worries. Click “submit”.

Create a Deployment

  1. Go to the Deployments menu, then click on “New Deployment”.
  2. On the “Deployment Settings” page, give the deployment a name. Leave all defaults alone for now. This will be a Non-HA build to start. Click “Next”.
  3. On the “Network Configuration” page, we’ll drag and drop the subnets that we created earlier. The “default” is pre-dropped. Drag the “External” to Public, and “Tenant” to Tunnel. Click “Next”.
  4. On the “Services Overview” page, you configure nothing. Simply peruse the list of services that will be deployed and running on the different nodes. “Click Next”.
  5. On the “Services Configuration” page, leave “VXLAN” checked, as well as ML2 Core. On the left had column, click on “Cinder”. Click “Submit”.

You now have a “Deployment” (mostly) configured. What do I mean by that? Well, now you need to PXE boot your systems, assign those systems, then be sure that their respective IP addresses are assigned*. Refer back to “part 1” for the diagram to see what nodes need what interfaces.

*This is a big friggin’ deal. If the installer does not see that the node in question has the appropriate number of interfaces, delete the node from the installer and reboot it. I say this from playing with the installer for a while now. If it doesn’t see the proper interfaces at original discovery it will not configure the interface properly and the final RHEL-OSP configuration for that node will not take. Save yourself the time. Trust me on this one. 🙂

Pulling it All Together

  1. If you haven’t already PXE booted all of your nodes, do so now. They should all come to a “Foreman Discovery” menu. You can hit “enter” or let it time out and go on its own. From there, the installer picks up the MAC address of the PXE interface and after a minute or so, the nodes will show up under the “Hosts” -> “Discovered hosts” page. More importantly, they will show up as available to be assigned under your newly created deployment.
  2. Under the listing of Deployment Roles (under your deployment that you created), there are 5 headings.. we are concerned with the first 3 only. In a non-HA configuration, there can only be 1 Controller, but there can be multiple Neutron nodes and multiple Compute nodes. For our purposes, we will deploy one of each. To assign a discovered node, simply click on the “+” next to the role, and click a check box next to the appropriate node(s), then click “assign”. Then go to the next role, so on and so forth. DO NOT CLICK DEPLOY YET!!!
  3. Don’t click deploy yet. (did I catch you in time?)
  4. Before you click “deploy”, we need to double check our networking. It’s easy. Click the “clock” icon next to the role name, then the node name, then the “edit” button. Finally, click “Network”. This is where having all of the necessary interfaces recognized is so important. The “primary” interface for each node is likely going to be the “default/PXE/mgmt” network, and likely does not need to be manipulated. The next interface is (in my lab) the Tunnel/Private/VXLAN/(or GRE) network (Neutron and Compute nodes only), so choose the proper subnet from the drop down and give it an IP from that subnet. Check “managed”. The final interface is the External/Public interface (Neutron node only), so choose the proper subnet from the dropdown and give it an IP from that subnet. Check “managed”.
  5. Click “Submit”, then click back to your new deployment. Now you can click “Deploy”. It will deploy in a serial fashion – Controller, Neutron, then Compute. Give it about 20-30 minutes a host.

Here’s the video walk through (Like the other videos, it looks good in full screen – just give it a few seconds to come into focus:

Ok, unfortunately, that’s all the time we have.. but I promise to follow up quickly with a troubleshooting guide.

Hope this helps,

Captain KVM

Agree? Disagree? Something to add to the conversation?