How to get started with Razor and Puppet – Part 3

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?

Advertisements

About Jonas Rosland

Open Source Community Manager at {code} by Dell EMC
This entry was posted in Automation, EMC, Installation, IT Transformation, Puppet, Razor, VMware. Bookmark the permalink.

6 Responses to How to get started with Razor and Puppet – Part 3

  1. Swapnil says:

    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.

  2. Swapnil Mankar says:

    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?

    • jonas says:

      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!

  3. Michael Lozano says:

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s