Razor - Installers, Policies and Tags

This is part 4 of a series of posts on the new version of razor-server

1. Installing Razor - Yes the New Version..
2. Razor - DHCP and TFTP
3. Installing the Razor client and creating a repository
4. Installers, Policies and Tags
5. Razor - What Lies Within the installer?
6. Installing ESXi with Razor

We are almost ready to deploy our first node but in order for that to happen - we will need the following.

• Installer - the set of commands that will be run to deploy the OS
• Broker - the next step for the installation of the node - usually the orchestration software
• Policy - this will contain the repository name, the installer name
• Hostname pattern - the naming policy for your deployed nodes
• Password - the root password for the deployed node
• Count - the maximum number of times you would like this policy to be applied
• Tags - How to identify the node - based on the hardware reported. In the previous post we created a single repository - ESXi_5_1. The details of the repository are below.

razor repos "ESXi_5_1"

Create a broker. In our case - this will be the noop broker - which means that nothing will happen after the node has been provisioned.

razor create-broker --name=noop --broker-type=noop
razor brokers

Create a tag.

Before we go into how the tags are created - I would like to explain in a bit more detail, what the tags are used for.
The microkernel’s main purpose is to scan the hardware of the node, and report that inventory back to the Razor server. With that information we can create categories/profiles/flavors of nodes - and deploy a operating to that node.
Let’s take an example. You have a UCS Chassis. You want to deploy ESXi on the Blades that have 128GB of RAM, but on the UCS blades that have 64GB of RAM you don’t want ESXi, but rather RHEL6. You also have an HP Chassis with 16 blades, and there you want to deploy ESXi on all the servers.
If we were to verbally describe the tags they would be as follows.

For our example we will be creating a test rule and it’s appropriate tag. The tag definitions will be:

• 2 processors
• It is a virtual machine
• Greater/equal to 4GB ram

cat > tag1.json << __CREATE_TAG_JSON___****{  
  "name": "Test_tag",  
  "rule": ["and",  
["=", ["num", ["fact", "processorcount"]], 2],  
["=", ["fact", "is_virtual"], "true"],  
[">=", ["num", ["fact", "memorysize_mb"]], 4096]  
   ]  
}__CREATE_TAG_JSON___

razor create-tag --json tag1.json  
razor tags Test_tag  

Now to create the policy.

cat > policy.json << __CREATE_POLICY_JSON___  
{  
  "name": "ESXi_5_1",  
  "repo": { "name": "ESXi_5_1" },  
  "installer": { "name": "vmware_esxi" },  
  "broker": { "name": "noop" },  
  "enabled": true,  
  "hostname": "host${id}.maishsk.local",  
  "root_password": "blahblahbb5",  
  "max_count": "100",  
  "rule_number": "100",  
  "tags": [{ "name": "Test_tag"}]  
}  
__CREATE_POLICY_JSON___ 

The text above is piped to the policy.json file.

Let’s go into a bit more detail into each of the lines of this policy.

name - The name of the policy
repo - The name of the repository that should be used to perform the deployment
installer - The name of the installer to be used - The name that should be used is the name of the yaml file (without the extension) which can be found in the /opt/razor-server/installers/ directory.

broker - Which broker should be used to continue the configuration, in our case the noop broker - which means nothing will happen.
enabled - True or false - you can create a policy and not have it active - if you choose.
hostname - The pattern that will be used to name your nodes. host${id}.maishsk.local (id is the number that was allocated to the node) - the rest you can customize as you please.
root_password - The root password that will be configured on the node.
max_count - The number of times the policy should be applied.
rule_number - This allows you to prioritize your policies. Lower number wins
tag - The tag that the node will be matched against.

razor create-policy --json policy.json  
razor policies ESXi_5_1  

The steps above were split into two stages, but there is also a possibility of creating the tag and the policy in the step, all you will need to do is define the rule in the policy.json - when the tag is declared.
Instead of this line

"tags": [{ "name": "Test_tag"}]

You could do the exact same thing without creating the tag beforehand with the following syntax (all should be on one line)

"tags": [ "name": "Test_tag", "rule": ["and",["=", ["num", ["fact", "processorcount"]], 2], ["=", ["fact", "is_virtual"], "true"], [">=", ["num", ["fact", "memorysize_mb"]], 4096]]]

The difference in the syntax above is that we defined the rule of the tag - during the creation of the policy.
That was a lot of information to digest in this post, so I hope you were able to get it all in.
In the next post - we will go into a little more detail about the installers and their configuration.