Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Installing Contrail with OpenStack by Using Juju Charms

You can deploy Contrail by using Juju Charms. Juju helps you deploy, configure, and efficiently manage applications on private clouds and public clouds. Juju accesses the cloud with the help of a Juju controller. A Charm is a module containing a collection of scripts and metadata and is used with Juju to deploy Contrail.

Contrail supports the following charms:

  • contrail-agent

  • contrail-analytics

  • contrail-analyticsdb

  • contrail-controller

  • contrail-keystone-auth

  • contrail-openstack

These topics describe how to deploy Contrail by using Juju Charms.

Preparing to Deploy Contrail by Using Juju Charms

Follow these steps to prepare for deployment:

  1. Install Juju.
  2. Configure Juju.

    You can add a cloud to Juju, identify clouds supported by Juju, and also manage clouds already added to Juju.

    • Adding a cloud—Juju recognizes a wide range of cloud types. You can use any one of the following methods to add a cloud to Juju:

      • Adding a Cloud by Using Interactive Command

        Example: Adding an MAAS cloud to Juju

        Note:

        Juju 2.x is compatible with MAAS series 1.x and 2.x.

      • Adding a Cloud Manually

        You use a YAML configuration file to add a cloud manually. Enter the following command:

        For an example, to add the cloud junmaas, assuming that the name of the configuration file in the directory is maas-clouds.yaml, you run the following command:

        The following is the format of the YAML configuration file:

        Note:

        The auth-types for a MAAS cloud type is oauth1.

    • Identifying a supported cloud

      Juju recognizes the cloud types given below. You use the juju clouds command to list cloud types that are supported by Juju.

  3. Create a Juju controller.
    Note:

    A Juju controller manages and keeps track of applications in the Juju cloud environment.

Deploying Contrail Charms

You can deploy Contrail Charms in a bundle or manually.

Deploy Contrail Charms in a Bundle

Follow these steps to deploy Contrail Charms in a bundle.

  1. Deploy Contrail Charms.

    To deploy Contrail Charms in a bundle, use the juju deploy <bundle_yaml_file> command.

    The following example shows you how to use bundle_yaml_file to deploy Contrail on Amazon Web Services (AWS) Cloud.

    You can create or modify the Contrail Charm deployment bundle YAML file to:

    • Point to machines or instances where the Contrail Charms must be deployed.

    • Include the options you need.

      Each Contrail Charm has a specific set of options. The options you choose depend on the charms you select. For more information on the options that are available, see Options for Juju Charms.

  2. (Optional) Check the status of deployment.

    You can check the status of the deployment by using the juju status command.

  3. Enable configuration statements.

    Based on your deployment requirements, you can enable the following configuration statements:

Deploying Juju Charms with OpenStack Manually

Before you begin deployment, ensure that you have:

  • Installed and configured Juju

  • Created a Juju controller

  • Ubuntu 16.04 or Ubuntu 18.04 installed

Follow these steps to deploy Juju Charms manually:

  1. Create machine instances for OpenStack, compute, and Contrail.
  2. Deploy OpenStack services.

    You can deploy OpenStack services by using any one of the following methods:

    • By specifying the OpenStack parameters in a YAML file

      The following is an example of a YAML-formatted (nova-compute-config.yaml) file.

      Use this command to deploy OpenStack services by using a YAML-formatted file:

    • By using CLI

      To deploy OpenStack services through the CLI:

    • By using a combination of YAML-formatted file and CLI

      To deploy OpenStack services by using a combination of YAML-formatted file and CLI:

      Note:

      Use the --to <machine number> command to point to a machine or container where you want the application to be deployed.

      Note:

      You set OpenStack services on different machines or on different containers to prevent HAProxy conflicts from applications.

  3. Deploy and configure nova-compute.
    Note:

    You can deploy nova-compute to more than one compute machine.

    (Optional) To add additional computes:

  4. Deploy and configure Contrail services.
  5. Enable applications to be available to external traffic:
  6. Enable contrail-controller and contrail-analytics services to be available to external traffic if you do not use HAProxy.
  7. Apply SSL.

    You can apply SSL if needed. To use SSL with Contrail services, deploy easy-rsa service and add-relation command to create relations to contrail-controller service and contrail-agent services.

  8. (Optional) HA configuration.

    If you use more than one controller, follow the HA solution given below:

    1. Deploy HAProxy and Keepalived services.

      HAProxy charm is deployed on machines with Contrail controllers. HAProxy charm must have peering_mode set to active-active. If peering_mode is set to active-passive, HAProxy creates additional listeners on the same ports as other Contrail services. This leads to port conflicts.

      Keepalived charm does not require to option.

    2. Enable HAProxy to be available to external traffic.
      Note:

      If you enable HAProxy to be available to external traffic, do not follow step 6.

    3. Add HAProxy and Keepalived relations.
    4. Configure contrail-controller service with VIP.
  9. Add other necessary relations.

Options for Juju Charms

Each Contrail Charm has a specific set of options. The options you choose depend on the charms you select. The following tables list the various options you can choose:

  • Options for contrail-agent Charms.

    Table 1: Options for contrail-agent

    Option

    Default option

    Description

    physical-interface

    Specify the interface where you want to install vhost0 on. If you do not specify an interface, vhost0 is installed on the default gateway interface.

    vhost-gateway

    auto

    Specify the gateway for vhost0. You can enter either an IP address or the keyword (auto) to automatically set a gateway based on the existing vhost routes.

    remove-juju-bridge

    true

    To install vhost0 directly on the interface, enable this option to remove any bridge created to deploy LXD/LXC and KVM workloads.

    dpdk

    false

    Specify DPDK vRouter.

    dpdk-driver

    uio_pci_generic

    Specify DPDK driver for the physical interface.

    dpdk-hugepages

    70%

    Specify the percentage of huge pages reserved for DPDK vRouter and OpenStack instances.

    dpdk-coremask

    1

    Specify the vRouter CPU affinity mask to determine on which CPU the DPDK vRouter will run.

    dpdk-main-mempool-size

    Specify the main packet pool size.

    dpdk-pmd-txd-size

    Specify the DPDK PMD Tx Descriptor size.

    dpdk-pmd-rxd-size

    Specify the DPDK PMD Rx Descriptor size.

    docker-registry

    opencontrailnightly

    Specify the URL of the docker-registry.

    docker-registry-insecure

    false

    Specify if the docker-registry should be configured.

    docker-user

    Log in to the docker registry.

    docker-password

    Specify the docker-registry password.

    image-tag

    latest

    Specify the docker image tag.

    log-level

    SYS_NOTICE

    Specify the log level for Contrail services.

    Options: SYS_EMERG, SYS_ALERT, SYS_CRIT, SYS_ERR, SYS_WARN, SYS_NOTICE, SYS_INFO, SYS_DEBUG

    http_proxy

    Specify URL.

    https_proxy

    Specify URL.

    kernel-hugepages-1g

    Parameter not enabled by default.

    Note:

    2MB huge pages for kernel-mode vRouters are enabled by default.

    Specify the number of 1G huge pages for use with vRouters in kernel mode.

    You can enable huge pages to avoid compute node reboots during software upgrades.

    This parameter must be specified at initial deployment. It cannot be modified in an active deployment. If you need to migrate to huge page usage in an active deployment, use 2MB huge pages if suitable for your environment.

    We recommend allotting 2GB of memory—either using the default 1024x2MB huge page size setting or the 2x1GB size setting—for huge pages. Other huge page size settings should only be set by expert users in specialized circumstances.

    1GB and 2MB huge pages cannot be enabled simultaneously in environments using Juju. If you are using this command parameter to enable 1GB huge pages, you must also disable 2MB huge pages. 2MB huge pages can be disabled by entering the juju config contrail-agent kernel-hugepages-2m=““ command with an empty value.

    A compute node reboot is required to enable a huge page setting configuration change. After this initial reboot, compute nodes can complete software upgrades without a reboot.

    Huge pages are disabled for kernel-mode vRouters if the kernel-hugepages-1g and the kernel-hugepages-2m options are not set.

    This parameter was introduced in Contrail Networking Release 2005.

    kernel-hugepages-2m

    1024

    Specify the number of 2MB huge pages for use with vRouters in kernel mode. Huge pages in Contrail Networking are used primarily to allocate flow and bridge table memory within the vRouter. Huge pages for kernel-mode vRouters provide enough flow and bridge table memory to avoid compute node reboots to complete future Contrail Networking software upgrades.

    1024x2MB huge pages are configured by default starting in Contrail Networking Release 2005. A compute node reboot is required to enable a kernel-mode vRouter huge page setting configuration change, however, so this huge page setting is not enabled on a compute node until the compute node is rebooted.

    After a compute node is rebooted to enable a vRouter huge page setting, compute nodes can complete software upgrades without a reboot.

    We recommend allotting 2GB of memory—either using the default 1024x2MB huge page size setting or the 2x1GB size setting—for kernel-mode vRouter huge pages. Other huge page size settings should only be set by expert users in specialized circumstances.

    1GB and 2MB huge pages cannot be enabled simultaneously in environments using Juju. If you are using this command parameter to enable 2MB huge pages, you must also disable 1GB huge pages. 1GB huge pages are disabled by default and can also be disabled by entering the juju config contrail-agent kernel-hugepages-1g=““ command with an empty value. 1GB huge pages can only be enabled at initial deployment; you cannot initially enable 1GB huge pages in an active deployment.

    Huge pages are disabled for kernel-mode vRouters if the kernel-hugepages-1g and the kernel-hugepages-2m options are not set.

    no_proxy

    Specify the list of destinations that must be directly accessed.

  • Options for contrail-analytics Charms.

    Table 2: Options for contrail-analytics

    Option

    Default option

    Description

    control-network

    Specify the IP address and network mask of the control network.

    docker-registry

     

    Specify the URL of the docker-registry.

    docker-registry-insecure

    false

    Specify if the docker-registry should be configured.

    docker-user

    Log in to the docker registry.

    docker-password

    Specify the docker-registry password.

    image-tag

     

    Specify the docker image tag.

    log-level

    SYS_NOTICE

    Specify the log level for Contrail services.

    Options: SYS_EMERG, SYS_ALERT, SYS_CRIT, SYS_ERR, SYS_WARN, SYS_NOTICE, SYS_INFO, SYS_DEBUG

    http_proxy

    Specify URL.

    https_proxy

    Specify URL.

    no_proxy

    Specify the list of destinations that must be directly accessed.

  • Options for contrail-analyticsdb Charms.

    Table 3: Options for contrail-analyticsdb

    Option

    Default option

    Description

    control-network

    Specify the IP address and network mask of the control network.

    cassandra-minimum-diskgb

    256

    Specify the minimum disk requirement.

    cassandra-jvm-extra-opts

    Specify the memory limit.

    docker-registry

     

    Specify the URL of the docker-registry.

    docker-registry-insecure

    false

    Specify if the docker-registry should be configured.

    docker-user

    Log in to the docker registry.

    docker-password

    Specify the docker-registry password.

    image-tag

     

    Specify the docker image tag.

    log-level

    SYS_NOTICE

    Specify the log level for Contrail services.

    Options: SYS_EMERG, SYS_ALERT, SYS_CRIT, SYS_ERR, SYS_WARN, SYS_NOTICE, SYS_INFO, SYS_DEBUG

    http_proxy

    Specify URL.

    https_proxy

    Specify URL.

    no_proxy

    Specify the list of destinations that must be directly accessed.

  • Options for contrail-controller Charms.

    Table 4: Options for contrail-controller

    Option

    Default option

    Description

    control-network

    Specify the IP address and network mask of the control network.

    auth-mode

    rbac

    Specify the authentication mode.

    Options: rbsc, cloud-admin, no-auth.

    For more information, see https://github.com/Juniper/contrail-controller/wiki/RBAC.

    cassandra-minimum-diskgb

    20

    Specify the minimum disk requirement.

    cassandra-jvm-extra-opts

    Specify the memory limit.

    cloud-admin-role

    admin

    Specify the role name in keystone for users who have admin-level access.

    In environments using Canonical orchestration with Contrail Networking, you should change the cloud-admin-role to Admin with a capital A in most scenarios. The default cloud admin role in Contrail Networking is admin and the default cloud admin role in Canonical is Admin. These cloud admin role names must match to grant users admin-level access. You can ensure this matching by setting this field to Admin in environments using the default settings.

    global-read-only-role

    Specify the role name in keystone for users who have read-only access.

    vip

    Specify if the Contrail API VIP is used for configuring client-side software. If not specified, private IP of the first Contrail API VIP unit will be used.

    use-external-rabbitmq

    false

    To enable the Charm to use the internal RabbitMQ server, set use-external-rabbitmq to false.

    To use an external AMQP server, setuse-external-rabbitmq to true.

    Note:

    Do not change the flag after deployment.

    flow-export-rate

    0

    Specify how many flow records are exported by vRouter agent to the Contrail Collector when a flow is created or deleted.

    docker-registry

     

    Specify the URL of the docker-registry.

    docker-registry-insecure

    false

    Specify if the docker-registry should be configured.

    docker-user

    Log in to the docker registry.

    docker-password

    Specify the docker-registry password.

    image-tag

     

    Specify the docker image tag.

    log-level

    SYS_NOTICE

    Specify the log level for Contrail services.

    Options: SYS_EMERG, SYS_ALERT, SYS_CRIT, SYS_ERR, SYS_WARN, SYS_NOTICE, SYS_INFO, SYS_DEBUG

    http_proxy

    Specify URL.

    https_proxy

    Specify URL.

    no_proxy

    Specify the list of destinations that must be directly accessed.

  • Options for contrail-keystone-auth Charms.

    Table 5: Options for contrail-keystone-auth

    Option

    Default option

    Description

    ssl_ca

    Specify if the base64-encoded SSL CA certificate is provided to Contrail keystone clients.

    Note:

    This certificate is required if you use a privately signed ssl_cert and ssl_key.

  • Options for contrail-openstack Charms.

    Table 6: Options for contrail-controller

    Option

    Default option

    Description

    enable-metadata-server

    true

    Set enable-metadata-server to true to configure metadata and enable nova to run a local instance of nova-api-metadata for virtual machines

    use-internal-endpoints

    false

    Set use-internal-endpoints to true for OpenStack to configure services to use internal endpoints.

    heat-plugin-dirs

    /usr/lib64/heat,/usr /lib/heat/usr/lib/ python2.7/dist-packages/ vnc_api/gen/heat/ resources

    Specify the heat plugin directories.

    docker-registry

     

    Specify the URL of the docker-registry.

    docker-registry-insecure

    false

    Specify if the docker-registry should be configured.

    docker-user

    Log in to the docker registry.

    docker-password

    Specify the docker-registry password.

    image-tag

     

    Specify the docker image tag.

    log-level

    SYS_NOTICE

    Specify the log level for Contrail services.

    Options: SYS_EMERG, SYS_ALERT, SYS_CRIT, SYS_ERR, SYS_WARN, SYS_NOTICE, SYS_INFO, SYS_DEBUG

    http_proxy

    Specify URL.

    https_proxy

    Specify URL.

    no_proxy

    Specify the list of destinations that must be directly accessed.

Ironic Support with Juju

Contrail Networking Release 2011.L1 supports new charms for Ironic from OpenStack Train version 15.x.x. Ironic is an OpenStack project that manages Bare Metal Servers (BMS) as if they are virtual machines (VM)s. For more information about Contrail and BMS, see Bare Metal Server Management.

Contrail Networking Release 2011.L2 supports OpenStack Ussuri with Ironic deployed on Ubuntu version 20.04 (Focal Fossa).

The updated options are shown in the example bundle_yaml_file. Before deploying the updated yaml file, you should have Ceph installed. If not, see Installing Ceph.

For information about deploying the bundle_yaml_file, see Deploying Contrail Charms.

Following is an example bundle_yaml_file with the additional options highlighted. ceph-radosgw and its related options are required to support the new Ironic charms.

Release History Table
Release
Description
2011.L2
Contrail Networking Release 2011.L2 supports OpenStack Ussuri with Ironic deployed on Ubuntu version 20.04 (Focal Fossa).
2011.L1
Contrail Networking Release 2011.L1 supports new charms for Ironic from OpenStack Train version 15.x.x.