Configure node before Network Config

In specific deployments, it is required to perform additional configurations on the overcloud node before network deployment, but after applying kernel args. For example, OvS-DPDK deployment requires DPDK to be enabled in OpenvSwitch before network deployment (os-net-config), but after the hugepages are created (hugepages are created using kernel args). This requirement is also valid for some 3rd party SDN integration. This kind of configuration requires additional TripleO service definitions. This document explains how to achieve such deployments on and after train release.

Note

In queens release, the resource PreNetworkConfig can be overridden to achieve the required behavior, which has been deprecated from train onwards. The implementations based on PreNetworkConfig should be moved to other available alternates.

The TripleO service OS::TripleO::BootParams configures the parameter KernelArgs and reboots the node using the tripleo-ansible role tripleo_kernel. Some points to consider on KernelArgs:

• BootParams service is enabled by default on all the roles.

• The node will be restarted only when kernel args are applied for the first time (fresh node configuration).

• In case of adding KernelArgs during update/upgrade/scale operations, when a particular role does not have KernelArgs, it results in node reboot. Such scenarios should be treated as role migration instead adding only KernelArgs.

• KernelArgs can be updated from wallaby release onwards (where the role already has KernelArgs but requires modification). In such cases, the node reboot has to be planned by the user manually, after the TripleO deployment is completed. For example, increasing the hugepages count post deployment.

The firstboot scripts provide a mechanism to apply the custom node configuration which is independent of kernel args.

Custom Service

When a configuration needs to be applied on the node after reboot and before the network config, then a custom service template should be added that includes the BootParams resource (example below) and any other required configuration. It is important to allow the default implementation of BootParams service to be included as it is, because any improvements or fixes will be automatically included in the deployment.

Here is an example OvS-DPDK has been configured after BootParams but before network config:

heat_template_version: wallaby

description: >
  Open vSwitch Configuration

parameters:
  ServiceData:
    default: {}
    description: Dictionary packing service data
    type: json
  ServiceNetMap:
    default: {}
    description: Mapping of service_name -> network name. Typically set
                 via parameter_defaults in the resource registry. Use
                 parameter_merge_strategies to merge it with the defaults.
    type: json
  RoleName:
    default: ''
    description: Role name on which the service is applied
    type: string
  RoleParameters:
    default: {}
    description: Parameters specific to the role
    type: json
  EndpointMap:
    default: {}
    description: Mapping of service endpoint -> protocol. Typically set
                 via parameter_defaults in the resource registry.
    type: json

resources
  BootParams:
    type: /usr/share/openstack-tripleo-heat-templates/deployments/kernel/kernel-boot-params-baremetal-ansible.yaml
    properties:
      ServiceData: {get_param: ServiceData}
      ServiceNetMap: {get_param: ServiceNetMap}
      EndpointMap: {get_param: EndpointMap}
      RoleName: {get_param: RoleName}
      RoleParameters: {get_param: RoleParameters}

outputs:
  role_data:
    description: Role data for the Open vSwitch service.
    value:
      service_name: openvswitch
      deploy_steps_tasks:
        - get_attr: [BootParams, role_data, deploy_steps_tasks]
        - - name: Run ovs-dpdk role
            when: step|int == 0
            include_role:
              name: tripleo_ovs_dpdk

Note

In the above sample service definition, the condition step|int == 0 in the deploy_steps_tasks section forces the associated steps to run before starting any other node configuration (including network deployment).

Add this service to the roles definition of the required roles so that the configuration can be applied after reboot but before network deployment.