The Chef Provisioning Library Architecture

###Overview In order to make better use of HPE OneView, it would be good to have an architectural overview of how Chef and it's provisioning "frameworks" provide the functionality to drive OneView. The provisining library (or framework with it's plugin architecture) is hosted on github here [https://github.com/chef/chef-provisioning](Chef Provisioning).

###Chef Provisioning Architecture The Chef provisioning library gives the ability to create/manage various infrastructure resources such as Machines(physical/virtual), networking devices such as load balancers and cloud instances. These resources can be expanded with the use of a plugin architecture allowing chef to manipulate infrastructure regardless of vendor. Currently there are drivers allowing Chef to manage VMware vSphere, Amazon EC2, LXC, Docker, VirtualBox, bare metal, HPE Oneview and more..

The HPE OneView implementation expands the machine resource configuration in a recepie to allow chef to control HPE OneView and also HPE Insight Control Server Provisioning. The HPE OneView driver conforms to the Chef provisioning library and exposes configuration details such as OneView Templates and ICSP build plans that Chef can then use to create Infrastructure.

The key component to a recipe is the action that will be performed, these actions define the type of configuration that will take place and they also drive the chef provisioning library to call certain functions within the HPE OneView driver.

###Machine actions

All of the machine actions are defined here. The HPE OneView driver supports all these actions, but here we'll highlight three specific actions:

:convergeThis action is meant to provide the full lifecycle of steps, from defining physical infrastructure with a OneView template to deploying an operating system and then finally installing the chef-client.

:destroyThis action removes the machine and returns it's capacity to be used for something else.

:stop This simply powers off a machine.

####Functions called in the driver This is a deep dive into what is happening under the covers when the :converge action is called in a recipe.

Example Recipe:

require 'chef/provisioning'
with_driver 'oneview'
machine 'chef' do
  recipe 'my_server_cookbook::default'
  # Action to be performed on this server
  action :converge
  # Options are :converge :destroy :stop
  machine_options :driver_options => {
  ... configuration details
  }

The first line of this recipe invokes the Chef Provisioning library require 'chef/provisioning' and this ensures that Chef will run this recipe in a particular manner. The second line with_driver 'oneview' has chef load up the HPE OneView Chef driver and check it for syntax/configuration errors. The line machine 'chef' do defines the machine that is to be acted upon, dependent on the action being performed. The action being passed is action :converge, and this action will perform a number function calls and make use of the configuration defined in the section titled machine_options :driver_options => {...}.

####Behind the scenes

with_driver 'oneview' - This will call the function def initialize(canonical_url, config) in the oneview driver that will test the configuration specified in knife.rb. It will attempt to log into HPE OneView and ICSP and retrieve API versions.

action :converge - This will call a number of functions in a serial fashion that will provide and build infrastructure as defined in the recipe.

Step 1:

Chef provisioning will call the allocate_machine(action_handler, machine_spec, machine_options) function that will see if this machine has been created before (exists in chef-server), if not it will call the create_machine() funtion.

Step 1a:

The create_machine(action_handler, machine_spec, machine_options) function will first log into OneView and ICSP and then attempt to see if a server profile for this machine has already been created. If not then it will handle the steps to find the server template defined in the driver_options. Once the template has been located, it will then find some free hardware that matches the hardware type defined in the template. It will then power that hardware off and ask OneView to apply the template to that hardware and return it's created profile.

Step 2:

Chef provisioning will then call the read_machine(action_handler, machine_spec, machine_options) method, this will test that a server profile has been created correctly and further call the customize_machine(...) method that will take care of the OS installation with ICSP.

Step 2a:

The customize_machine(action_handler, machine_spec, machine_options, profile) method will log back into OneView and ICSP again, and ensure that the profile has been applied in OneView succesfully or wait for upto 60 minutes for the profile to complete (Otherwise it will timeout with an error). It will then power on that server, and attempt to PXE boot it where ICSP will then automate all of the build details outlined in the OS build plan. It will also pass all of the other customize build details to ICSP for further customization during the OS build.

Step 2b

The next and final converge method is the machine_for(machine_spec, machine_options) that will finalise the server that has been defined in HPE Oneview and has been configured and built with HPE ICSP. This method will attempt to find an external IP address of the operating system installed on the provisioned server, it will then use the Chef provisioning methods to install the chef-client so that further configuration work can be managed end-to-end through chef.