Skip to content

README.md

Latest commit

 

History

History
230 lines (180 loc) · 8.04 KB

README.md

File metadata and controls

230 lines (180 loc) · 8.04 KB

Cloudify Utilities: Configuration

Configuration plugin manual for VCPE solution

Preparation

Create a list of parameters that take part in your deployment, Map between the parameters you have listed and nodes you have, several parameters are going to be used by almost every node and others are going to just be used by 2 or 3 nodes.

Writing the Blueprint

Create main input

This input will hole initial parameter for the deployment. The input can be either in Dictionary or in JSON Formats.

Example

  parameters_json:
    default:
      Private: true
      Voice: true
      Public: true
      CPESerialNumber: CV3816AF0569

Create configuration holder node

configuration holder will hold the entire configuration in it’s runtime properties It will also be used as a target in relationships with nodes consuming the configuration

Example

  configuration:
    type: cloudify.nodes.ConfigurationLoader
    properties:
      parameters_json: { get_input: parameters_json }

Create function nodes

Specify the relevant parameters The relevant parameters specified will be taken from the global configuration stored in the configuration node and populated in to the runtime properties of the node instance. In the properties section create a key “params_list” inside this key create a list of the relevant parameters for this node.

Hard code parameters (Optional)

It is possible to hardcode and overwrite some of the parameters rather than taking the from the global configuration. This is useful when you have similar nodes with small differences that you want to hardcode. For example, the Master/Slave node configuration will be similar except the setting who is master and who is slave.

Define the Interfaces

This can be done ether individually or by using a node type, The interfaces usually are used are start, stop and update. The plugin will call the update interface during the update workflow. The interface should use the parameters found in “params” runtime properties, which is managed by the configuration plugin.

Update interface

In the update interface, new keys are added to the params runtime property.

  • diff_params - a list of changed parameters
  • old_params - previous version of all parameters, (non recursive - will hold only one version back).

Relationship to the configuration Node

This relationship calls the function which will populate the nodes runtime properties with the values relevant as specified in the params_list

Function Example

  l3GW_primary:
    type: juniper_node_config
    properties:
      netconf_auth:
        user: { get_input: netconf_user }
        password: { get_input: netconf_password }
        ip: { get_input: l3gw_primary_ip }
        key_content: { get_input: netconf_key_content }
        port: { get_input: netconf_port }
      params_list:
        - RouteExternal
        - RouteInternal
        - JpPrimary
        - JpSecondary
        - RoutePublic
        - RouteNat
      params:
        JpPrimary: True
        JpSecondary: False
    interfaces:
      cloudify.interfaces.lifecycle:
        start:
          inputs:
            strict_check: false
            template: xmls/l3gw-start.txt
            deep_error_check: true
            params: { get_attribute: [SELF, params] }
        stop:
          inputs:
            strict_check: false
            template: xmls/l3gw-stop.txt
            deep_error_check: true
            params: { get_attribute: [SELF, params] }
        update:
          inputs:
            strict_check: false
            template: xmls/l3gw-update.txt
            deep_error_check: true
            params: { get_attribute: [SELF, params] }
    relationships:
      - type: cloudify.relationships.load_from_config
        target: configuration

Using the configuration plugin with templates

It is possible to benefit form a powerful combination when the configuration plugin is combined with Terminal, Netconf or Script plugins. The Templates are rendered via the Jinja2 framework that provides powerful capabilities including loops, statements and calculations.

Netconf plugin

Netconf plugin supports templates and all have to be done is point the params interface input to instance runtime properties parameters (which is populated via the configuration plugin).

Example

  start:
    inputs:
      strict_check: false
      template: xmls/l3gw-start.txt
      deep_error_check: true
      params: { get_attribute: [SELF, params] }

Terminal plugin

Terminal plugin supports templates and all have to be done is point the params in call list to instance runtime properties parameters (which is populated via the configuration plugin).

Example

  start:
    inputs:
      terminal_auth:
      ..
      calls:
        - template: templates/fortigate.cmd
          params:  { get_attribute: [SELF, params] }

Script plugin

In script plugin in order to use the templates functionality, you can use the download_resource_and_render function. In the template point the parameters to the params runtime property.

Example

Blueprint:

  start:
    Implementation: scriptis/example_start.sh

Script:

#!/bin/bash
ctx download-resource-and-render templates/template.txt

Template:

config global
config system interface
edit "{{ ctx.instance.runtime_properties.params.CustInterfaceName }}_IN"

Provided types

configuration_loader

Configuration loader holds the entire configuration in it’s runtime properties.

Derived From: cloudify.nodes.ApplicationServer

Properties:

  • parameters_json: List of parameters for node.

Workflow inputs

  • configure:
    • parameters: By default used values from parameters_json property. Store all values to runtime properties. Possible to use json encoded values or dictionary.

Runtime properties:

  • params: storage for all configuration parameters, required for relationship lifecycle.

Relationships:

  • cloudify.relationships.load_from_config: Derived from cloudify.relationships.depends_on and must be used with target node only, e.g.: cloudify.nodes.terminal.Raw. Update params in depended node by filter in params_list and is called before configuration action in node.

Examples:

Simple example

Provided workflow

configuration_update

Workflow for update all nodes with types from node_types_to_update by values from configuration_node_id. Executes cloudify.interfaces.lifecycle.is_alive workflow only on relevant nodes, configure operation on the configuration_loader node provided in configuration_node_id paramter, preconfigure operation on every connected node to configuration_loader and finally cloudify.interfaces.lifecycle.update.

Parameters:

  • params: list of parameters.
  • configuration_node_id: type of configuration node, by default: configuration_loader.
  • node_types_to_update: list of node types for update in workflow, by default: juniper_node_config, fortinet_vnf_type.
  • merge_dict: boolean parameter

cloudify.interfaces.lifecycle.is_alive

Interface needs to implement operations needed to check if node that we want to configure is accessable to get updated. Unavailability can be handled in a few ways - performing operations that get back node to operability or raising NonRecoverableError that will stop execution of the workflow.

cloudify.interfaces.lifecycle.update

Interface implementing operation executing on the configuration update.