7 Other Topics #

Names are generated by the configuration processor for all allocated IP addresses. A server connected to multiple networks will have multiple names associated with it. One of these may be assigned as the hostname for a server via the network-group configuration (see Section 6.12, “NIC Mappings”). Names are generated from data taken from various parts of the input model as described in the following sections.

Names generated for servers in a cluster have the following form:

CLOUD-CONTROL-PLANE-CLUSTERMEMBER-PREFIXMEMBER_ID-NETWORK

Example: ardana-cp1-core-m1-mgmt

Names generated for servers in a resource group have the following form:

CLOUD-CONTROL-PLANE-RESOURCE-PREFIXMEMBER_ID-NETWORK

Example: ardana-cp1-comp0001-mgmt

The configuration processor makes allocation decisions on servers and IP addresses which it needs to remember between successive runs so that if new servers are added to the input model they do not disrupt the previously deployed allocations.

To allow users to make multiple iterations of the input model before deployment SUSE OpenStack Cloud will only persist data when the administrator confirms that they are about to deploy the results via the "ready-deployment" operation. To understand this better, consider the following example:

Imagine you have completed your SUSE OpenStack Cloud deployment with servers A, B, and C and you want to add two new compute nodes by adding servers D and E to the input model.

When you add these to the input model and re-run the configuration processor it will read the persisted data for A, B, and C and allocate D and E as new servers. The configuration processor now has allocation data for A, B, C, D, and E -- which it keeps in a staging area (actually a special branch in Git) until we get confirmation that the configuration processor has done what you intended and you are ready to deploy the revised configuration.

If you notice that the role of E is wrong and it became a swift node instead of a nova node you need to be able to change the input model and re-run the configuration processor. This is fine because the allocations of D and E have not been confirmed, and so the configuration processor will re-read the data about A, B, C and re-allocate D and E now to the correct clusters, updating the persisted data in the staging area.

You can loop though this as many times as needed. Each time, the configuration processor is processing the deltas to what is deployed, not the results of the previous run. When you are ready to use the results of the configuration processor, you run ready-deployment.yml which commits the data in the staging area into the persisted data. The next run of the configuration processor will then start from the persisted data for A, B, C, D, and E.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
-e remove_deleted_servers="y"

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
-e free_unused_addresses="y"

The configuration processor allocates servers to a cluster or resource group in the following sequence:

Once the configuration processor has allocated a server to a cluster or resource group it uses the information in the associated interface-model to determine which networks need to be configured. It does this by:

If there is no network available to a server, either because the interface-model does not include the required network-group, or there is no network from that group in the appropriate part of the server-groups hierarchy, then the configuration processor will generate an error.

The configuration processor will also generate an error if the server address does not match any of the networks it will be connected to.

Once the configuration processor has allocated all of the required servers and matched them to the appropriate networks, it validates that all service-components have the required network routes to other service-components.

It does this by using the data in the services section of the input model which provides details of which service-components need to connect to each other. This data is not configurable by the administrator; however, it is provided as part of the SUSE OpenStack Cloud release.

For each server, the configuration processor looks at the list of service-components it runs and determines the network addresses of every other service-component it needs to connect to (depending on the service, this might be a virtual IP address on a load balancer or a set of addresses for the service).

If the target address is on a network that this server is connected to, then there is no routing required. If the target address is on a different network, then the Configuration Processor looks at each network the server is connected to and looks at the routes defined in the corresponding network-group. If the network-group provides a route to the network-group of the target address, then that route is considered valid.

Networks within the same network-group are always considered as routed to each other; networks from different network-groups must have an explicit entry in the routes stanza of the network-group definition. Routes to a named network-group are always considered before a "default" route.

A warning is given for any routes which are using the "default" route since it is possible that the user did not intend to route this traffic. Such warning can be removed by adding the appropriate network-group to the list of routes.

The configuration processor provides details of all routes between networks that it is expecting to be configured in the info/route_info.yml file.

To illustrate how network routing is defined in the input model, consider the following example:

A compute server is configured to run nova-compute which requires access to the neutron API servers and a block storage service. The neutron API servers have a virtual IP address provided by a load balancer in the INTERNAL-API network-group and the storage service is connected to the ISCSI network-group. nova-compute itself is part of the set of components attached by default to the MANAGEMENT network-group. The intention is to have virtual machines on the compute server connect to the block storage via the ISCSI network.

The physical network is shown below:

The corresponding entries in the network-groups are:

  - name: INTERNAL-API
    hostname-suffix: intapi

    load-balancers:
       - provider: ip-cluster
         name: lb
         components:
           - default
         roles:
           - internal
           - admin

       - name: MANAGEMENT
         hostname-suffix: mgmt
         hostname: true

         component-endpoints:
           - default

         routes:
           - INTERNAL-API
           - default

       - name: ISCSI
         hostname-suffix: iscsi

         component-endpoints:
            - storage service

And the interface-model for the compute server looks like this:

  - name: INTERFACE_SET_COMPUTE
    network-interfaces:
      - name: BOND0
        device:
           name: bond0
        bond-data:
           options:
              mode: active-backup
              miimon: 200
              primary: hed5
           provider: linux
           devices:
              - name: hed4
              - name: hed5
        network-groups:
          - MANAGEMENT
          - ISCSI

When validating the route from nova-compute to the neutron API, the configuration processor will detect that the target address is on a network in the INTERNAL-API network group, and that the MANAGEMENT network (which is connected to the compute server) provides a route to this network, and thus considers this route valid.

When validating the route from nova-compute to a storage service, the configuration processor will detect that the target address is on a network in the ISCSInetwork group. However, because there is no service component on the compute server connected to the ISCSI network (according to the network-group definition) the ISCSI network will not have been configured on the compute server (see Section 7.5, “Server Network Selection”. The configuration processor will detect that the MANAGEMENT network-group provides a "default" route and thus considers the route as valid (it is, of course, valid to route ISCSI traffic). However, because this is using the default route, a warning will be issued:

#   route-generator-2.0       WRN: Default routing used between networks
The following networks are using a 'default' route rule. To remove this warning
either add an explicit route in the source network group or force the network to
attach in the interface model used by the servers.
  MANAGEMENT-NET-RACK1 to ISCSI-NET
    ardana-ccp-comp0001
  MANAGEMENT-NET-RACK 2 to ISCSI-NET
    ardana-ccp-comp0002
  MANAGEMENT-NET-RACK 3 to SCSI-NET
    ardana-ccp-comp0003

To remove this warning, you can either add ISCSI to the list of routes in the MANAGEMENT network group (routed ISCSI traffic is still a valid configuration) or force the compute server to attach to the ISCSI network-group by adding it as a forced-network-group in the interface-model, like this:

  - name: INTERFACE_SET_COMPUTE
      network-interfaces:
        - name: BOND0
          device:
            name: bond0
          bond-data:
            options:
               mode: active-backup
               miimon: 200
               primary: hed5
            provider: linux
            devices:
               - name: hed4
               - name: hed5
          network-groups:
             - MANAGEMENT
          forced-network-groups:
             - ISCSI

With the attachment to the ISCSI network group forced, the configuration processor will attach the compute server to a network in that group and validate the route as either being direct or between networks in the same network-group.

The generated route_info.yml file will include entries such as the following, showing the routes that are still expected to be configured between networks in the MANAGEMENT network group and the INTERNAL-API network group.

  MANAGEMENT-NET-RACK1:
     INTERNAL-API-NET:
        default: false
        used_by:
           nova-compute:
              neutron-server:
              - ardana-ccp-comp0001
   MANAGEMENT-NET-RACK2:
     INTERNAL-API-NET:
        default: false
        used_by:
          nova-compute:
            neutron-server:
            - ardana-ccp-comp0003

neutron provider VLANs are networks that map directly to an 802.1Q VLAN in the cloud provider’s physical network infrastructure. There are four aspects to a provider VLAN configuration:

The physical network infrastructure must be configured to convey the provider VLAN traffic as tagged VLANs to the cloud compute nodes and neutron network nodes. Configuration of the physical network infrastructure is outside the scope of the SUSE OpenStack Cloud 9 software.

SUSE OpenStack Cloud 9 automates the server networking configuration and the neutron configuration based on information in the cloud definition. To configure the system for provider VLANs, specify the neutron.networks.vlan tag with a provider-physical-network attribute on one or more network-groups as described in Section 6.13.2, “Network Tags”. For example (some attributes omitted for brevity):

  network-groups:

    - name: NET_GROUP_A
      tags:
        - neutron.networks.vlan:
              provider-physical-network: physnet1

    - name: NET_GROUP_B
      tags:
        - neutron.networks.vlan:
              provider-physical-network: physnet2

A network-group is associated with a server network interface via an interface-model as described in Section 6.11, “Interface Models”. For example (some attributes omitted for brevity):

  interface-models:
     - name: INTERFACE_SET_X
       network-interfaces:
        - device:
              name: bond0
          network-groups:
            - NET_GROUP_A
        - device:
              name: hed3
          network-groups:
            - NET_GROUP_B

A network-group used for provider VLANs may contain only a single SUSE OpenStack Cloud network, because that VLAN must span all compute nodes and any neutron network nodes/controllers (that is, it is a single L2 segment). The SUSE OpenStack Cloud network must be defined with tagged-vlan: false, otherwise a Linux VLAN network interface will be created. For example:

  networks:
     - name: NET_A
       tagged-vlan: false
       network-group: NET_GROUP_A
     - name: NET_B
       tagged-vlan: false
       network-group: NET_GROUP_B

When the cloud is deployed, SUSE OpenStack Cloud 9 will create the appropriate bridges on the servers, and set the appropriate attributes in the neutron configuration files (for example, bridge_mappings).

After the cloud has been deployed, create neutron network objects for each provider VLAN using the OpenStackClient CLI:

tux > sudo openstack network create --provider:network_type vlan \
--provider:physical_network PHYSNET1 --provider:segmentation_id 101 MYNET101

tux > sudo openstack network create --provider:network_type vlan \
--provider:physical_network PHYSNET2 --provider:segmentation_id 234 MYNET234

All the example configurations use a “deployer-in-the-cloud” scenario where the first controller is also the deployer/Cloud Lifecycle Manager. If you want to use a standalone Cloud Lifecycle Manager, you need to add the relevant details in control_plane.yml, servers.yml and related configuration files. Detailed instructions are available at Section 12.1, “Using a Dedicated Cloud Lifecycle Manager Node”.