Please read the comments, updates there!
Razor has gotten a CLI and API update, making some of the commands shown here not work correctly. If you come across something that doesn’t work, please look at the Razor wiki for help regarding that command.
So I realize I haven’t really spent time on explaining why we’ve installed Puppet yet, except as an alternative installation method to apt-get. That’s ok. I’ll do that in a bit. Not right now though, as I promised I’ll go in a bit more into the Tags system that you can utilize with Razor. And it will make a whole lot more sense if we do it in this order, trust me.
So, Tags. What are they, and what can we do with them?
Well, according to the documentation found here, we can use it to trigger a policy just like we saw on the example in Part 2. In that example, we had a node that looked like this:
root@puppet:~# razor node Discovered Nodes UUID Last Checkin Status Tags 2lrdkDEZNwDWm7h41oCmlk 7 sec A [IntelCorporation,memsize_1GiB,cpus_2,vmware_vm,nics_1]
The Tags that we found on that server were automatically set when Razor did a discovery of the node. There are a lot more things that has already been discovered, and you can see all of it if you run the “razor node get attrib UUID” command (scroll down and read carefully, it’s a long one):
root@puppet:~# razor node get attrib 2lrdkDEZNwDWm7h41oCmlk Node Attributes: Name Value architecture i386 boardmanufacturer Intel Corporation boardserialnumber None hardwareisa unknown hardwaremodel i686 hostname mk000C29E1EEE7 interfaces dummy0,eth0,lo ipaddress 192.168.72.102 ipaddress_eth0 192.168.72.102 ipaddress_lo 127.0.0.1 is_virtual true macaddress C2:0C:0F:F9:7D:FC macaddress_dummy0 C2:0C:0F:F9:7D:FC macaddress_eth0 00:0C:29:E1:EE:E7 manufacturer VMware, Inc. memorysize 1005.62 MB memorytotal 1005.62 MB mk_hw_bus_description Motherboard mk_hw_bus_physical_id 0 mk_hw_bus_serial None mk_hw_bus_vendor Intel Corporation mk_hw_bus_version None mk_hw_cpu0_bus_info cpu@0 mk_hw_cpu0_capacity 4230MHz mk_hw_cpu0_description CPU mk_hw_cpu0_physical_id 4 mk_hw_cpu0_serial 0002-0655-0000-0000-0000-0000 mk_hw_cpu0_size 2533MHz mk_hw_cpu0_slot CPU socket #0 mk_hw_cpu0_vendor Intel Corp. mk_hw_cpu0_version 6.5.5 mk_hw_cpu0_width 64 bits mk_hw_cpu1_bus_info cpu@1 mk_hw_cpu1_capacity 4230MHz mk_hw_cpu1_description CPU mk_hw_cpu1_physical_id 5 mk_hw_cpu1_product Pentium II mk_hw_cpu1_serial 0002-0655-0000-0000-0000-0000 mk_hw_cpu1_size 2533MHz mk_hw_cpu1_slot CPU socket #1 mk_hw_cpu1_vendor GenuineIntel mk_hw_cpu1_version 6.5.5 mk_hw_cpu_count 2 mk_hw_disk0_bus_info scsi@2:0.0.0 mk_hw_disk0_description SCSI Disk mk_hw_disk0_logical_name /dev/sda mk_hw_disk0_physical_id 0.0.0 mk_hw_disk0_size 20GiB (21GB) mk_hw_disk_count 1 mk_hw_fw_date 06/02/2011 mk_hw_fw_description BIOS mk_hw_fw_physical_id 0 mk_hw_fw_size 87KiB mk_hw_fw_vendor Phoenix Technologies LTD mk_hw_fw_version 6.00 mk_hw_lscpu_Architecture i686 mk_hw_lscpu_BogoMIPS 5056.74 mk_hw_lscpu_Byte_Order Little Endian mk_hw_lscpu_CPU_MHz 2527.079 mk_hw_lscpu_CPU_family 6 mk_hw_lscpu_CPU_op-modes 32-bit, 64-bit mk_hw_lscpu_CPU_sockets 1 mk_hw_lscpu_L1d_cache 32K mk_hw_lscpu_L1i_cache 32K mk_hw_lscpu_L2_cache 256K mk_hw_lscpu_L3_cache 3072K mk_hw_lscpu_Model 37 mk_hw_lscpu_Stepping 5 mk_hw_lscpu_Vendor_ID GenuineIntel mk_hw_mem_description System Memory mk_hw_mem_physical_id e2 mk_hw_mem_size 1GiB mk_hw_mem_slot System board or motherboard mk_hw_nic0_bus_info pci@0000:02:01.0 mk_hw_nic0_capacity 1Gbit/s mk_hw_nic0_clock 66MHz mk_hw_nic0_description Ethernet interface mk_hw_nic0_logical_name eth0 mk_hw_nic0_physical_id 1 mk_hw_nic0_serial 00:0c:29:e1:ee:e7 mk_hw_nic0_size 1Gbit/s mk_hw_nic0_version 01 mk_hw_nic0_width 64 bits mk_hw_nic_count 1 netmask 255.255.255.0 netmask_eth0 255.255.255.0 netmask_lo 255.0.0.0 network_eth0 192.168.72.0 network_lo 127.0.0.0 physicalprocessorcount 1 processorcount 1 productname VMware Virtual Platform type Other virtual vmware
TONS of information! So why is all this information important? Well, depending on the different characteristics of the hardware you want to provision, you can easily define new Tags with different usages. Say you have a new Cisco server, you boot it up, it will connect to the Razor PXE boot environment and spill the beans, so to say. You’ll get all the hardware info you need, and you can easily identify this server as a Cisco server. You then create a new Tag on this server, saying it’s a Cisco server, and you can later use this to tell the system that all servers that are tagged as Cisco servers should be installed with Ubuntu 12.04.
But first let’s look at how we can use the Tag system in the environment we’ve already built. First, let’s create a new tag that will make sense, how about a rule that says we should only install Ubuntu if the machine has one and only one drive. Two drives = no Ubuntu for you!
root@puppet:~# razor tag add name=onlyonedisk tag=onlyonedisk Name => onlyonedisk Tags => onlyonedisk UUID => 446ZHGlApOaIEpOB5f4Dya Matcher => <none>
Ok, cool, we’ve added a tag called “onlyonedisk”, got an UUID, but we’re missing a Matcher. Matchers are being used to match up things that we’ve gotten from the node attributes as seen above. Let’s create one for this tag using the node attribute mk_hw_disk_count! But first, some command help to get you started as it’s not clearly documented yet:
root@puppet:~# razor tag matcher add [Tag] [add_matcher] <-Must Provide Tag Rule UUID [tag_rule_uuid] Command help: razor tag matcher add tag_rule_uuid=(tag rule key) key=(key) compare=[equal|like] value=(value) {invert=(yes)} tag rule uuid: Is the UUID of the parent Tag Rule to add the matcher to key: the Node attribute key to match against compare: Either [equal] for literal matching or [like] for regular expression value: the value to match against the key inverse(OPTIONAL): inverts so result is true if key does NOT match value
Now let’s add the Tag Matcher!
root@puppet:~# razor tag matcher add tag_rule_uuid=446ZHGlApOaIEpOB5f4Dya key=mk_hw_disk_count compare=equal value=1 Tag Matcher created: Key => mk_hw_disk_count Compare => equal Value => 1 Inverse => false UUID => 4u8Tl6HO4ZMp3IQeOfMKTw
Ok, so now we have a Tag with a Tag Matcher, let’s see how they are connected:
root@puppet:~# razor tag Tag Rules Name Tags UUID Matchers [count] onlyonedisk onlyonedisk 446ZHGlApOaIEpOB5f4Dya 1 root@puppet:~# razor tag get 446ZHGlApOaIEpOB5f4Dya Name => onlyonedisk Tags => onlyonedisk UUID => 446ZHGlApOaIEpOB5f4Dya Matcher => 4u8Tl6HO4ZMp3IQeOfMKTw - 'mk_hw_disk_count' (equal) '1' root@puppet:~# razor tag matcher 4u8Tl6HO4ZMp3IQeOfMKTw Key => mk_hw_disk_count Compare => equal Value => 1 Inverse => false UUID => 4u8Tl6HO4ZMp3IQeOfMKTw
Ok, that’s cool. We have a Tag and a Tag Matcher, what does this mean for us? Well, have a look at the command “razor node” now…
root@puppet:~# razor node Discovered Nodes UUID Last Checkin Status Tags 2lrdkDEZNwDWm7h41oCmlk 310.1 min B [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_2,vmware_vm,nics_1]
It automatically has the new Tag we defined! How cool is that?!
So, now we have a new Tag, and we can use this on both Nodes and Policies. Nodes are automatically updated if a Tag matches the node attribute, but a Policy must be manually updated.
Let’s update our already existing policy with a new required Tag.
root@puppet:~# razor policy Policies # Enabled Label Tags Model Label #/Max Counter UUID 0 true precise [cpus_2,memsize_1GiB,vmware_vm] install_precise 1/- 1 Yf6unMzUdX68qdzpi9sFU root@puppet:~# razor policy Yf6unMzUdX68qdzpi9sFU UUID => Yf6unMzUdX68qdzpi9sFU Line Number => 0 Label => precise Enabled => true Template => linux_deploy Description => Policy for deploying a Linux-based operating system. Tags => [cpus_2, memsize_1GiB, vmware_vm] Model Label => install_precise Broker Target => none Currently Bound => 1 Maximum Bound => 0 Bound Counter => 1 root@puppet:~# razor policy update Yf6unMzUdX68qdzpi9sFU --tags cpus_2,memsize_1GiB,vmware_vm,onlyonedisk UUID => Yf6unMzUdX68qdzpi9sFU Line Number => 0 Label => precise Enabled => true Template => linux_deploy Description => Policy for deploying a Linux-based operating system. Tags => [cpus_2, memsize_1GiB, vmware_vm, onlyonedisk] Model Label => install_precise Broker Target => none Currently Bound => 1 Maximum Bound => 0 Bound Counter => 1
Let’s create two new VMs and test this new policy! Create two default Ubuntu VMs, one with one disk, and the other with two disks. Boot them up!
Booting up first VM with one disk gives this result:
root@puppet:~# razor node Discovered Nodes UUID Last Checkin Status Tags 2lrdkDEZNwDWm7h41oCmlk 318.0 min B [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_2,vmware_vm,nics_1] 5o9WouLjpHrPWx1UVf9WMq 2 sec A [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_1,vmware_vm,nics_1]
Booting up the second VM with two disks gives the following result:
root@puppet:~# razor node Discovered Nodes UUID Last Checkin Status Tags 2lrdkDEZNwDWm7h41oCmlk 319.6 min B [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_2,vmware_vm,nics_1] 5o9WouLjpHrPWx1UVf9WMq 33 sec A [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_1,vmware_vm,nics_1] 7XwetUEIIXcmVj7NbHufei 3 sec A [IntelCorporation,memsize_1GiB,cpus_1,vmware_vm,nics_1]
No onlyonedisk Tag there, awesome! So now we know that our Ubuntu installations will only be run on those nodes that will satisfy our required tags, which might calm down your nerves a bit. No, we will not reformat your entire server infrastructure with Ubuntu, just the ones that matches our Tags 🙂
This can of course be expanded into looking at server vendors, nic count, disk sizes etc, meaning you can have a Policy which will only deploy Cisco servers with 192GB RAM and 4CPUs on a specific subnet.
I hope this will get you started with the immensly useful Tags that are included in Razor, and makes it a bit easier to understand how we can use this to our advantage when wanting to deploy Ubuntu, Red Hat, VMware ESXi and so forth only on those servers that are meant for it.
Next up, the handoff to Puppet. Or is there something else you’d like to know before we head off there?
pureVirtual 
I am eagerly waiting for the part-4 on handoff. I looked everywhere but could not get much info about the handoff process or how it works.
It’s coming, should be done later this week or early next week. Hang in there!
I had a question on tagging. Is there a way to tag a new VM for provisioning? Lets say we have two VMs with the same configuration – same number of drives, same number of cpus etc. In this case can we assign a different tag to each of the VMs so that we can have Ubuntu 11.10 on one and maybe Ubuntu 12.04 on the other?
Yes, you can use a separate tags for different installation methods.
Create two differents policies with different installation methods and add tags to them, like this:
razor policy update –tags cpus_2,memsize_1GiB,vmware_vm,onlyonedisk,ubuntu1110
razor policy update –tags cpus_2,memsize_1GiB,vmware_vm,onlyonedisk,ubuntu1204
The VMs might be exactly the same in hardware configuration, but they will still have different MAC addresses (also shown in the “Hardware ID” section of “razor node”). So we can add those MAC addresses into a “tag matching” rule:
root@puppet:~# razor node 1cdXm6THZ6wwSfznmyUZQ8
UUID => 1cdXm6THZ6wwSfznmyUZQ8
Last Checkin => 07-11-12 22:12:09
Status => bound
Tags => [onlyonedisk,IntelCorporation,memsize_1GiB,cpus_1,vmware_vm,nics_1]
Hardware IDs => [000C29E1EEE7]
root@puppet:~# razor node get attrib 1cdXm6THZ6wwSfznmyUZQ8
macaddress_eth0 00:0C:29:E1:EE:E7
root@puppet:~# razor tag add name=ubuntu1110 tag=ubuntu1110
Name => ubuntu1110
Tags => ubuntu1110
UUID => 70XjcIpiLW5MkQXYPywFcm
Matcher =>
root@puppet:~# razor tag matcher add tag_rule_uuid=70XjcIpiLW5MkQXYPywFcm key=macaddress_eth0 compare=equal value=00:0C:29:E1:EE:E7
Tag Matcher created:
Key => macaddress_eth0
Compare => equal
Value => 00:0C:29:E1:EE:E7
Inverse => false
UUID => IXyW9UhK2IJqlKZwTzLJQ
Now, do a razor node command again:
root@puppet:~# razor node 1cdXm6THZ6wwSfznmyUZQ8
UUID => 1cdXm6THZ6wwSfznmyUZQ8
Last Checkin => 07-11-12 22:12:09
Status => bound
Tags => [ubuntu1110,onlyonedisk,IntelCorporation,memsize_1GiB,cpus_1,vmware_vm,nics_1]
Hardware IDs => [000C29E1EEE7]
There we have it, a matching rule for that specific machine to booted into a Ubuntu 11.10 installation.
If you need to update the “tag matcher” for another Hardware ID/MAC address, do this:
root@puppet:~# razor tag matcher update IXyW9UhK2IJqlKZwTzLJQ key=macaddress_eth0 compare=equal value=
Of course you can also play around with regular expressions like “compare=like value=00:0C:29*” if you have several machines using a similar MAC address that will have the same policy applied to them.
Happy tagging!
I’m getting the sense that some of the command syntax has changed. To get node attributes, I had to use: razor node get [UUID] -f attrib
Same with the tag matcher: sudo razor tag [TAG_UUID] matcher add -k mk_hw_disk_count -c equal -v 1