Cisco Cisco Intelligent Automation for Cloud 4.2 Installation Guide
11
Installing and Configuring Optional Software
Configuring Puppet Labs for Cisco IAC Integration
Note:
For vCenter, Cisco IAC automatically configures new Puppet nodes to have VMware Tools synchronize the clock
with the ESXi host; therefore, the best way to achieve clock synchronization is to ensure that the ESXi hosts and the
Puppet Master use the same time authority to set the time.
Puppet Master use the same time authority to set the time.
If the Puppet master requires a private key file to connect, you will need to specify this with the Connect Cloud
Infrastructure or Update Cloud Infrastructure service. Check the Additional Options check box to specify this.
Infrastructure or Update Cloud Infrastructure service. Check the Additional Options check box to specify this.
If you need to use an alternative repository for the Puppet Enterprise Installer, you can override the default Puppet Labs
location with the Connect Cloud Infrastructure or Update Cloud Infrastructure service. Choose the Additional Options
check box to specify a different base URL. The installer files must match the Puppet Labs naming conventions exactly.
location with the Connect Cloud Infrastructure or Update Cloud Infrastructure service. Choose the Additional Options
check box to specify a different base URL. The installer files must match the Puppet Labs naming conventions exactly.
You can override the location for the hiera node classification files with the Connect Cloud Infrastructure or Update Cloud
Infrastructure service. Choose the Additional Options check box to specify an override. You use
Infrastructure service. Choose the Additional Options check box to specify an override. You use
$environment
as a
placeholder in the path. Be sure your hiera.yaml file is modified accordingly.
Method for Sharing Facts Between Nodes and Stacks
When using Puppet with the Application Stack Accelerator Pack (ASAP), it is often necessary for one node in a stack to
be able to reference the facts of another (for example, the IP Address). This is achieved by recording the stack instance
name and the role in a stack as external facts for each node that can be used as lookup criteria. To query facts about the
other nodes in a stack you need to first have installed the prerequisite puppetdbquery module from
be able to reference the facts of another (for example, the IP Address). This is achieved by recording the stack instance
name and the role in a stack as external facts for each node that can be used as lookup criteria. To query facts about the
other nodes in a stack you need to first have installed the prerequisite puppetdbquery module from
https://forge.puppetlabs.com/dalen/puppetdbquery
.
Facts that Cisco IAC automatically assigns to nodes include:
stack_instance
: Name of the Stack Instance (shared by all servers in the same stack)
stack_role
: Role Name or List of Role Names (comma-separated) for the server
iac_organization:
Name of the IAC organization (including tenant prefix) for customer who ordered the stack
In your puppet code, use the following as an example of retrieving facts about another node in the stack.
$db_host_ip = query_nodes(“stack_instance=‘$stack_instance’ and stack_role~’(,|^)mysql (,|$)’)”
The query above returns the IP address for the node that has the role mysql in the same stack as the current node running
this code.
this code.
Working With Class Parameter Overrides
The IAC integration with Puppet allows class parameter value overrides to be configured and exposed to users ordering
servers. This is done through special JSON files that reside in the same location as your profile module’s puppet code
(under manifests). Class override parameters are always defined in the profile module, and, if present, have the same
name as profile or profile subclass followed by “.params.json”.
servers. This is done through special JSON files that reside in the same location as your profile module’s puppet code
(under manifests). Class override parameters are always defined in the profile module, and, if present, have the same
name as profile or profile subclass followed by “.params.json”.
Below is a sample of “webserver.params.json” corresponding to the profile class called “webserver”. For each
parameter, you provide a friendly name, description, default value, and most importantly, what class parameter you are
overriding. You can alternatively define an externally defined fact for a node by specifying ‘fact’, ‘factor’ or an empty value
for the class_param attribute of the parameter.
parameter, you provide a friendly name, description, default value, and most importantly, what class parameter you are
overriding. You can alternatively define an externally defined fact for a node by specifying ‘fact’, ‘factor’ or an empty value
for the class_param attribute of the parameter.
If you provide a comma-separated options list, users will have to choose one of the values in the list. Override values are
added to the hiera node classification file along with the role that includes the profiles requiring these parameter values.
Because class parameter overrides are handled in Hiera node classification, be careful of parameter override
precedence. Any values provided in a “class” inclusion block, will take precedence over those values provided by Hiera.
added to the hiera node classification file along with the role that includes the profiles requiring these parameter values.
Because class parameter overrides are handled in Hiera node classification, be careful of parameter override
precedence. Any values provided in a “class” inclusion block, will take precedence over those values provided by Hiera.
Profile Class Parameter Overrides JSON Example
{